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Banking and Financial Services Sectional Committee, MSD 7 



NATIONAL FOREWORD 

This Indian Standard which is identical with ISO 21 1 88 : 2006 'Public key infrastructure for financial 
services — Practices and policy framework' issued by the International Organization for Standardization 
(ISO) was adopted by the Bureau of Indian Standards on the recommendation of the Banking and 
Financial Services Sectional Committee and approval of the Management and Systems Division 
Council. 

The text of ISO Standard has been approved as suitable for publication as an Indian Standard without 
deviations. Certain conventions are, however, not identical to those used in Indian Standards. Attention 
is particularly drawn to the following : 

Wherever the words 'International Standard' appear referring to this standard, they should be 
read as 'Indian Standard'. 



In this adopted standard, reference appears to certain International Standards for which Indian 
Standards also exist. The corresponding Indian Standards which are to be substituted in their respective 
places are listed below along with their degree of equivalence for the editions indicated: 



International Standard 

ISO 781 : 1 985 Identification cards 

— Physical characteristics 

ISO/IEC 7811-1 1995^> 

Identification cards — Recording 
technique — Part 1 : Embossing 

ISO/IEC 7811-2 1995^> 

Identification cards — Recording 
technique — Part 2 : Magnetic stripe 

— Lowcoercivity 

ISO/IEC 7811-3 1985^> 

Identification cards — Recording 
technique — Part 3 : Location of 
embossed characters on ID-1 cards 

ISO/IEC 7811-4 1985^> 

Identification cards — Recording 
technique — Part 4 : Location 
of read-only magnetic track — Track 
1 &2 

ISO/IEC 7811-5 1985^> 

Identification cards — Recording 
technique — Part 5 : Location 
of read-write magnetic track — 
Tracks 3 



Corresponding Indian Standard 

IS 14172 : 1994 Identification cards 

— Physical characteristics 

IS 1 41 47 (Part 1 ) : 2003 Identification 
cards — Recording technique: Part 1 
Embossing {first revision) 

IS 1 41 47 (Part 2) : 2003 Identification 
cards — Recording technique: Part 2 
Magnetic stripe — Low coercivity 
{first revision) 

IS 1 41 47 (Part 3) : 1 994 Identification 
cards — Recording technique: Part 3 
Location of embossed characters on 
ID-1 cards 

IS 1 41 47 (Part 4) : 1 994 Identification 
cards — Recording technique: Part 4 
Location of read-only magnetic track 

— Track 1 & 2 

IS 1 41 47 (Part 5) : 1 994 Identification 
cards — Recording technique: Part 5 
Location of read-write magnetic track 

— Tracks 3 



Degree of Equivalence 
Identical 

do 
do 



do 



do 



do 



The current version of various parts of ISO/IEC 781 1 is given below: 
ISO/IEC 7811-1 : 1995 Identification cards - Recording technique — Part 1 : Embossing 
ISO/IEC 7811-2 : 1995 Identification cards - Recording technique — Part 2 : Magnetic Stripe 
The parts 3, 4 and 5 of ISO/IEC 7811 have since been withdrawn. 



Low coercivity 



International Standard 

ISO/IEC 7813 : 2006 Identification 
cards — Financial transaction cards 

ISO 7816-1 : 1998 Identification 
cards — Integrated circuit cards 



ISO 7816-2 : 1999 Identification 
cards — Integrated circuit cards 



ISO/IEC 781 6-3 : 1 997 Identification 
cards — Integrated circuit cards 



ISO/IEC 781 6-5 : 1 994 Identification 
cards — Integrated circuit cards 



ISO/IEC 781 6-6 : 1 997 Identification 
cards — Integrated circuit cards 



ISO/IEC 15408-1 : 2005 Information 
technology — Security techniques 

— Evaluation criteria for IT security 

— Part 1 : Introduction and general 
model 

ISO/IEC 1 5408-2 : 2005 Information 
technology — Security techniques 

— Evaluation criteria for IT security 

— Part 2: Security functional 
requirements 

ISO/IEC 1 5408-3 : 2005 Information 
technology — Security techniques 

— Evaluation criteria for IT security 

— Part 3: Security assurance 
requirements 

ISO/IEC 17799 : 2005 Information 
technology — Security techniques 

— Code of practice for information 
security management 



Corresponding Indian Standard 

IS 14174 : 1994 Identification cards 

— Financial transaction cards 

IS 1 4202 (Part 1 ) : 2003 Identification 
cards — Integrated circuit(s) — 
Cards with contacts: Part 1 Physical 
characteristics (first revision) 

IS 1 4202 (Part 2) : 2003 Identification 
cards — Integrated circuit(s) — 
Cards with contacts: Part 2 
Dimensions and location of the 
contacts (first revision) 

IS 1 4202 (Part 3) : 2002 Identification 
cards — Integrated circuit(s) — 
Cards with contacts: Part 3 
Electronic signals and transmission 
protocols 

IS 1 4202 (Part 5) : 2003 Identification 
cards — Integrated circuit(s) — 
Cards with contacts: Part 5 
Registration system for applications 
in IC cards 

IS 1 4202 (Part 6) : 2003 Identification 
cards — Integrated circuit(s) — 
Cards with contacts: Part 6 
Interindustry data elements 

IS 1 4990 (Part 1 ) : 2006 Information 
technology — Security techniques 

— Evaluation criteria for IT security: 
Parti Introduction and general model 
(first revision) 

IS 1 4990 (Part 2) : 2006 Information 
technology — Security techniques 

— Evaluation criteria for IT security: 
Part 2 Security functional 
requirements (first revision) 

IS 1 4990 (Part 3) : 2006 Information 
technology — Security techniques 

— Evaluation criteria for IT security: 
Part 3 Security assurance 
requirements (first revision) 

IS/ISO/IEC 17799 : 2005 Information 
technology — Security techniques 

— Code of practice for information 
security management 
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Degree of Equivalence 
Identical 

do 
do 



do 



do 



do 



do 



do 



do 



do 



The technical committee has reviewed the provisions of the following International Standards referred 
in this adopted standard and has decided that they are acceptable for use in conjunction with this 
standard: 



International Standard 
ISO/IEC 781 6 
ISO/IEC 9594-8: 1995 



Title 
Identification cards — Integrated circuit cards (Part 4, 7 to 12 and 15) 

Information Technology — Open Systems Interconnection — The Directory: 
Authentication Framework 



III 
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International Standard 
ISO/IEC 9834-1 :1993 

ISO/IEC 10646-1 

ISO 15782-1 :2003 



Title 

Information technology — Open Systems Interconnection — Procedures for 
the operation of OSI Registration Authorities: General procedures — Part 1 

Information technology — Universal Multiple-Octet Coded Character Set 
(UCS) — Part 1 : Architecture and Basic Multilingual Plane 

Certificate management for financial services — Part 1 : Public key certificates 



IS0 15782-2 
IS0 18014-2 

IS0 18014-3 

ISO 18032 
ISO 18033 



Banking — Certificate management — Part 2: Certificate Extensions 

Information technology — Security techniques — Time-stamping services 

— Part 2: Mechanisms producing independent tokens 

Information technology — Security techniques — Time-stamping services 

— Part 3: Mechanisms producing linked tokens 

Information technology — Security techniques — Prime number generation 

Information technology — Security techniques — Encryption algorithms 
(Parts 1 to 4) 



All the eight parts of ISO 10202 'Financial transaction cards — Security architecture of financial 
transaction systems using integrated circuit cards' to which normative reference appears in the standard 
were adopted as various parts of IS 1 4958. The various parts of the International Standard ISO 1 0202 
as well as their corresponding adopted Indian Standards (various parts of IS 1 4958) have since been 
withdrawn. 



IV 
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Introduction 

Institutions and intermediaries are building infrastructures to provide new electronic financial transaction 
capabilities for consumers, corporations and government entities. As the volume of electronic financial 
transactions continues to grow, advanced security technology using digital signatures and authority systems 
can become part of the financial transaction process. Financial transaction systems incorporating advanced 
security technology have requirements to ensure the privacy, authenticity and integrity of financial transactions 
conducted over communications networks. 

The financial services industry relies on several time-honoured methods of electronically identifying, 
authorizing and authenticating entities and protecting financial transactions. These methods include, but are 
not limited to. Personal Identification Numbers (PINs) and Message Authentication Codes (MACs) for retail 
and wholesale financial transactions, user IDs and passwords for network and computer access, and key 
management for network connectivity. Over the last twenty years the financial services industry has 
developed risk management processes and policies to support the use of these technologies in financial 
applications. 

The expanded use of Internet technologies by the financial services industry and the needs of the industry in 
general to provide safe, private and reliable financial transaction and computing systems have given rise to 
advanced security technology incorporating public key cryptography. Public key cryptography requires a 
business-optimized infrastructure of technology, management and policy (a public key infrastructure or PKI, as 
defined in this document) to satisfy requirements of electronic identification, authentication, message integrity 
protection and authorization in financial application systems. The use of standard practices for electronic 
identification, authentication and authorization in a PKI ensures more consistent and predictable security in 
these systems and confidence in electronic communications. Confidence (e.g. trust) can be achieved when 
compliance to standard practices can be ascertained. 

Applications serving the financial services industry can be developed with digital signature and PKI 
capabilities. The safety and the soundness of these applications are based, in part, on implementations and 
practices designed to ensure the overall integrity of the infrastructure. Users of authority-based systems that 
electronically bind the identity of individuals and other entities to cryptographic materials (e.g. cryptographic 
keys) benefit from standard risk management systems and the base of auditable practices defined in this 
International Standard. 

Members of the International Organization of Standardization Technical Committee 68 have made a 
commitment to public key technology by developing technical standards and guidelines for digital signatures, 
key management, certificate management and data encryption. ISO 15782 parts 1 and 2 define a certificate 
management system for financial industry use, but does not include certificate policy and certification 
practices requirements. This International Standard complements ISO 15782 parts 1 and 2 by providing a 
framework for managing a PKI through certificate policies, certification practice statements, control objectives 
and supporting procedures. For implementers of these International Standards, the degree to which any entity 
in a financial transaction can rely on the implementation of public key infrastructure standards and the extent 
of interoperability between PKI-based systems using these International Standards will depend partly on 
factors relative to policy and practices defined in this document. 
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Indian Standard 

PUBLIC KEY INFRASTRUCTURE FOR 

FINANCIAL SERVICES — PRACTICES AND 

POLICY FRAMEWORK 



1 Scope 

This International Standard sets out a framework of requirements to manage a PKI through certificate policies 
and certification practice statements and to enable the use of public l<ey certificates in the financial services 
industry. It also defines control objectives and supporting procedures to manage risl<s. 

This International Standard draws a distinction between PKI systems used in open, closed and contractual 
environments. It further defines the operational practices relative to financial services industry accepted 
information systems control objectives. This International Standard is intended to help implementers to define 
PKI practices that can support multiple certificate policies that include the use of digital signature, remote 
authentication and data encryption. 

This International Standard facilitates the implementation of operational, baseline PKI control practices that 
satisfy the requirements for the financial services industry in a contractual environment. While the focus of this 
International Standard is on the contractual environment, application of this document to other environments is 
not specifically precluded. For the purposes of this document, the term "certificate" refers to public key 
certificates. Attribute certificates are outside the scope of this International Standard. 

This International Standard is targeted for several audiences having dissimilar needs and therefore the use of 
this document will have a different focus for each. 

Business Managers and Analysts are those who require information regarding using PKI technology in their 
evolving businesses (e.g., electronic commerce) and should focus on Clauses 1 to 6. 

Technical Designers and Implementers are those who are writing their certificate policy(ies) and 
certification practice statement(s) and should focus on Clauses 6 to 8 and Annexes A to F. 

Operational Management and Auditors are those who are responsible for day-to-day operations of the PKI 
and validating compliance to this document and should focus on Clauses 6 to 8. 



2 Normative references 

The following referenced documents are indispensable for the application of this document. For dated 
references, only the edition cited applies. For undated references, the latest edition of the referenced 
document (including any amendments) applies. 

ISO/IEC 7810, Identification cards — Pliysical cliaracteristics 

ISO/IEC 781 1 , Identification cards — Recording technique (parts 1 to 5) 

ISO/IEC 7813, Identification cards — Financial transaction cards 

ISO/IEC 7816, Identification cards — Integrated circuit cards (parts 1 to 12 and 15) 

ISO/IEC 9594-8:1995, /nformaf/on Technology — Open Systems Interconnection — The Directory: 
Authentication Framework 

1 
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ISO/IEC 9834-1:1993, //i/brAT7af/on technology — Open Systems Interconnection — Procedures for the 
operation of OSI Registration Authorities: General procedures — Part 1 

ISO 10202, Financial transaction cards — Security architecture of financial transaction systems using 
integrated circuit cards (eight parts) 

ISO/I EC 10646-1, Information technology — Universal Multiple-Octet Coded Character Set (UCS) — Part 1: 
Architecture and Basic Multilingual Plane 

ISO/IEC 15408, Information technology — Security techniques — Evaluation criteria for IT security (three 
parts) 

ISO 1 5782-1 :2003, Certificate management for financial services — Part 1: Public key certificates 

ISO 15782-2, Banking — Certificate Management — Part 2: Certificate Extensions 

ISO/IEC 17799, Information technology — Security techniques — Code of practice for information security 
management 

\S0 ^80^4-2, Information technology — Security techniques — Time-stamping services — Part 2: 
Mechanisms producing independent tokens 

\S0 18014-3, Information technology — Security techniques — Time-stamping services — Part 3: 
Mechanisms producing linked tokens 

ISO/IEC 18032, Information technology — Security techniques — Prime number generation 

ISO 18033, Information technology — Security techniques — Encryption algorithms (parts 1 to 4) 



3 Terms and definitions 

For the purposes of this document, the following terms and definitions apply. 

3.1 

activation data 

data values, other than keys, which are required to operate cryptographic modules and which need to be 
protected (e.g. a PIN, a pass phrase, a biometric, or a manually held key share) 

3.2 
authentication 

verification of an individual's claimed identity: 

a) at registration, the act of evaluating end entities' (i.e., subscribers') credentials as evidence for their 
claimed identity; 

b) during use, the act of comparing electronically submitted identity and credentials (i.e., user ID and 
password) with stored values to prove identity 

3.3 
autlientication data 

information used to verify the claimed identity of an entity, such as an individual, defined role, corporation or 
institution 

3.4 

card bureau 

agent of the CA (3.18) or RA (3.46) that personalizes an ICC (3.32) containing the subscriber's private key (as 
a minimum) 
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3.5 
cardholder 

subject to whom the integrated circuit card containing private and public l<ey pairs and certificates (3.6) has 
been issued 

3.6 
certificate 

public key and identity of an entity together with some other information, rendered unforgeable by signing the 
certificate information with the private key of the certifying authority that issued that public key certificate 

3.7 

certificate liold 

certificate suspension 

suspension of the validity of a certificate (3.6) 

3.8 

certificate issuer 

organization whose name appears in the issuer field of a certificate (3.6) 

3.9 

certificate manufacturer 

agent who performs the tasks of applying a digital signature to a certificate signing request on behalf of the 
certificate (3.6) issuer 

3.10 

certificate policy 

CP 

named set of rules that indicates the applicability of a certificate to a particular community and/or class of 
application with common security requirements 

3.11 

certificate profile 

specification of the required format (including requirements for the usage of standard fields and extensions) 
for a particular type of certificate (3.6) 

3.12 

certificate re-key 

process whereby an entity with an existing key pair and certificate (3.6) receives a new certificate for a new 
public key, following the generation of a new key pair 

3.13 

certificate renewal 

rollover 

process whereby an entity is issued a new instance of an existing certificate with a new validity period 

3.14 

certificate revocation list 

CRL 

list of revoked certificates (3.6) 

3.15 

certificate validation service 

service provided by the CA (3.18) or its agent which performs the task of confirming the validity of a 
certificate (3.6) to a relying party (3.49) 

3.16 

certificate validation service provider 

CVSP 

entity (3.29) that provides certificate validation services to its relying party customers 
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3.17 
certification 

process of creating a public l<ey certificate for an entity (3.29) 

3.18 

certification authority 

CA 

entity trusted by one or more entities to create, assign and revol<e or inold pubiic key certificates 

3.19 
certification patli 

ordered sequence of certificates of entities winicin, togetlner witin tine pubiic l<ey of tine initiai entity in tine patin, 
can be processed to obtain tine pubiic l<ey of Ihe finai entity in tine patti 

3.20 

certification practice statement 

CPS 

statement of tine practices winicin a certification autliority (3.18) empioys in issuing certificates and winicin 
defines tine equipment, poiicies and procedures tine CA uses to satisfy tine requirements specified in tine 
certificate poiicies tinat are supported by it 

3.21 

certification request 

submission of a vaiidated registration request by an RA (3.46), its agent or a subject to a CA (3.18) to register 
a subject's pubiic key to be piaced in a certificate (3.6) 

3.22 

certification response 

message sent, foiiowing certification, from a CA (3.18) in response to a certificate request 

3.23 

certificate validity 

validity 

appiicabiiity (fitness for intended use) and status (iive, suspended, revoked or expired) of a certificate (3.6) 

3.24 
compromise 

vioiation of tine security of a system sucli tliat an unautliorized disciosure of sensitive information may liave 
occurred 

3.25 

cross certification 

process by winicin two CAs (3.18) mutuaiiy certify eacin otiner's pubiic keys 

NOTE This process may or may not be automated. 

3.26 

cryptographic hardware 
cryptographic device 
hardware security module 

inardware cryptograplnic moduie 

3.27 

digital signature 

cryptograpinic transformation tinat, winen associated witli a data unit, provides tine services of origin 
autinentication, data integrity and signer non-repudiation 

3.28 

end entity 

certificate subject tinat uses its private key for purposes otiner tinan signing certificates 
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3.29 

entity 

CA (3.18), RA (3.46) or end entity (3.28) 

3.30 

event journal 
audit journal 
audit log 

chronological record of system activities which is sufficient to enable the reconstruction, review and 
examination of the sequence of environments and activities surrounding or leading to each event in the path 
of a transaction from its inception to the output of the final results 

3.31 

functional testing 

portion of security testing in which the advertised features of a system are tested for correct operation 

3.32 

integrated circuit card 

ICC 

card into which has been inserted one or more electronic components in the form of microcircuits to perform 
processing and memory functions 

3.33 

issuing certification authority 

issuing CA 

in the context of a particular certificate, the issuing CA (3.18) is the CA that issued the certificate 

3.34 

key escrow 

management function that allows access by an authorized party to a replicated private encipherment key 

NOTE This may be a legal requirement to allow law enforcement officials to gain access to an entity and/or CA's 

private confidentiality key. 

3.35 

key recovery 

ability to restore an entity's private key or a symmetric encipherment key from secure storage in the event that 
such keys are lost, corrupted or otherwise become unavailable 

3.36 

multiple control 

condition under which two (dual) or more parties separately and confidentially have custody of components of 
a single key that, individually, convey no knowledge of the resultant cryptographic key 

3.37 

object identifier 

OID 

unique series of integers that unambiguously identifies an information object 

3.38 

online certificate status mechanism 

mechanism that allows relying parties (3.49) to request and obtain certificate status information without 
requiring the use of CRLs (3.14) 

3.39 

online certificate status protocol 

OCSP 

protocol for determining the current status of a certificate in lieu of or as a supplement to checking against a 
periodic CRL (3.14) and which specifies the data that need to be exchanged between an application checking 
the status of a certificate and the server providing that status 
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3.40 

operating period 

period of a certificate beginning on tine date and time it is issued by a CA (3.18) (or on a later date and time, if 
stated in tine certificate), and ending on tine date and time it expires or is revol<ed 

3.41 

PKI disclosure statement 

document tinat supplements a CP (3.10) or CPS (3.20) by disclosing critical information about the policies and 
practices of a CA (3.18)/PKI (3.45) 

NOTE A PKI disclosure statement is a vehicle for disclosing and emphasizing information normally covered in detail 

by associated CP and/or CPS documents. Consequently, a PDS is not intended to replace a CP or CPS. 

3.42 

policy authority 

PA 

party or body with final authority and responsibility for specifying certificate policies (3.10) and ensuring CA 
(3.18) practices and controls as defined by the CPS (3.20) fully support the specified certificate policies 

3.43 

policy mapping 

recognition that, when a CA (3.18) in one domain certifies a CA in another domain, a particular certificate 
policy (3.10) in the second domain may be considered by the authority of the first domain to be equivalent 
(but not necessarily identical in all respects) to a particular certificate policy in the first domain 

NOTE See 3.25, cross certification. 

3.44 

policy qualifier 

policy-dependent information that accompanies a certificate policy (3.10) identifier in an X.509 certificate 

3.45 

public key infrastructure 

PKI 

structure of hardware, software, people, processes and policies that employs digital signature technology to 
facilitate a verifiable association between the public component of an asymmetric public key pair with a 
specific subscriber that possesses the corresponding private key 

NOTE The public key may be provided for digital signature verification, authentication of the subject in 

communication dialogues, and/or for message encryption key exchange or negotiation. 

3.46 

registration authority 

RA 

entity that is responsible for identification and authentication of subjects of certificates, but is not a CA (3.18), 
and hence does not sign or issue certificates 

NOTE An RA may assist in the certificate application process or revocation process or both. The RA does not need 

to be a separate body, but can be part of the CA. 

3.47 

registration request 

submission by an entity to an RA (3.46) [or CA (3.18)] to register the entity's public key in a certificate 

3.48 

registration response 

message sent by an RA (3.46) [or CA (3.18)] to an entity in response to a registration request 
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3.49 

relying party 
RP 

recipient of a certificate wino acts in reliance on tinat certificate, digital signatures verified using that certificate, 
or both 

3.50 
repository 

system for storage and distribution of certificates and related information (i.e., certificate storage, certificate 
distribution, certificate policy (3.10) storage and retrieval, certificate status, etc.) 

3.51 
root CA 

CA (3.18) at the apex of the CA hierarchy 

3.52 

signature verification 

(in relation to a digital signature) accurate determination: 

a) that the digital signature was created during the operational period of a valid certificate by the private key 
corresponding to the public key listed in the certificate (3.6); 

b) that the message has not been altered since its digital signature was created. 

3.53 
subject 

entity whose public key is certified in a public key certificate 

3.54 
subject CA 

CA (3.18) that is certified by the issuing CA and hence complies with the certificate policy (3.10) of the 
issuing CA 

3.55 

subject end entity 

end entity that is the subject of a certificate (3.6) 

3.56 

subordinate CA 
sub-CA 

CA (3.18) that is lower relative to another CA in the CA hierarchy 

3.57 
subscriber 

entity subscribing with a certification authority (3.18) on behalf of one or more subjects 

3.58 
superior CA 

CA (3.18) that is higher relative to another [subordinate CA (3.56)] in the CA hierarchy, but is not a root CA 

3.59 

tamper evident 

possessing a characteristic that provides evidence that an attack has been attempted 

3.60 

tamper resistant 

possessing a characteristic that provides passive physical protection against an attack 



IS/ISO 21188: 2006 



3.61 
trusted role 

job function that performs critical functions wliicli, if performed unsatisfactorily, may liave an adverse impact 
upon the degree of trust provided by the CA(3.18) 

3.62 

trust services provider 

TSP 

approved organization (as determined by the contractual participants) providing trust services, through a 
number of certification autliorities (3.18), to their customers who may act as subscribers or relying parties 
(3.49) 

NOTE A trust services provider may also provide certificate validation services. 

3.63 

validation service request 

enquiry by the relying party (3.49) to a validation service to check the validity of a certificate (3.6) 



4 Abbreviated terms 

Abbreviation IVIeaning 

ASN.1 Abstract Syntax Notation One 

CA Certification Authority 

CM Certificate Manufacturer 

CP Certificate Policy 

CPS Certification Practice Statement 

CRL Certificate Revocation List 

CVSP Certificate Validation Service Provider 

EMV Eurocard MasterCard Visa 

Fl Financial Institution 

FIPS Federal Information Processing Standard 

FTP File Transfer Protocol 

HSM Hardware Security Module 

HTTP Hypertext Transfer Protocol 

ICC Integrated Circuit Card 

ID Identifier 

lEC International Electrotechnical Commission 

IETF Internet Engineering Task Force 

ISO International Organization for Standardization 
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Abbreviation 


IVIeaning 


ITU 


International Telecommunications Union 


LDAP 


Lightweight Directory Access Protocol 


MAC 


Message Authentication Code 


OCSP 


Online Certificate Status Protocol 


OID 


Object Identifier 


PA 


Policy Authority 


PIN 


Personal Identification Number 


PKI 


Public Key Infrastructure 


PKIX 


Public Key Infrastructure (X.509) (lb 1 1- Working Group) 


POS 


Point Of Sale 


RA 


Registration Authority 


RFC 


Request For Comment 


RP 


Relying Party 


SSL 


Secure Sockets Layer 


TLS 


Transport Layer Security 


TSA 


Time stamping Authority 


TSP 


Trust Services Provider 


TTP 


Trusted Third Party 


URL 


Uniform Resource Locator 



5 Public key infrastructure (PKI) 

5.1 General 

Before addressing the details of PKI policy and practices requirements, this International Standard provides 
some background information in order for the reader to better understand the context In which these policies 
and practices are used within a PKI. 

5.2 What is PKI? 



This subclause describes the components of a PKI and Illustrates the roles with responsibilities undertaken by 
the various entities within the PKI. The rapid growth of electronic commerce has brought with it the desire to 
conduct business-to-business, business-to-consumer, and government-to-consumer transactions across open 
networks such as the Internet. The design of the network transmission protocols creates problems for financial 
institutions and their customers conducting business transactions, who require the electronic identification and 
authentication of the transacting parties, proof of origin, message integrity protection and confidentiality 
services. Electronic authentication also raises significant issues with respect to evidence and contract, liability, 
privacy, consumer protection and trade. 
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PKIs are a practical technical solution to the problems posed by open networks. Financial institutions are 
becoming trust services providers (TSPs), to take advantage of the growing market for security and 
authentication in online communications. Relying parties, as recipients of information, use TSPs to validate 
certificates used to authenticate on-line communications. A TSP is a recognized authority trusted by one or 
more relying parties to create and sign certificates. A TSP may also revoke certificates it has created and 
issued. A TSP operates one or more certification authorities (CAs) whose core functions are certificate issuing, 
manufacturing and certificate validation. Within a financial institution, a CA is not necessarily a business entity 
but may be a unit or a function providing CA functions that may be trusted by relying parties and subscribing 
parties. 

Public key technology is used to support confidentiality, integrity and authentication requirements. With public 
key cryptography, two keys are created (private and public). The private key is kept secret and the public key 
can be made publicly available in a certified form which protects its authenticity. The subject's public key and 
identifying data are signed by the CA's private key to create a certificate. Certificates are created under 
certificate policies. Revealing the public key does not compromise the private key. 

Financial institutions may use a PKI to service their business needs in the following environments depending 
upon their relationship with the relying party. Examples of each are provided in Tables 1 to 3. 

a) Closed environment: all entities (certificate subjects and relying parties) adhere'') to a single financial 
institution's trust service, and must share at least one certificate policy. See Figure 1 and Table 1 . 

b) Contractual environment: certificate subjects and relying parties may have separate TSPs. TSPs are 
bound by differing forms of contract covering certificate use. These forms comprise: 

1) multilateral, under agreed rules, with a single certificate policy; 

2) bilateral cross certification that may use different certificate policies; 

3) accreditation bridge that may recognize different certificate policies through central organization or 
entity. 

See Figure 2 and Table 2. 

c) Open environment: the financial institution may act as a TSP issuing certificates to the public and 
permits validation of certificates in an open network environment. TSPs may operate under voluntary TSP 
accreditation schemes or within an indigenous regulatory framework. Typically, there is no formal contract 
between the subscriber's TSP and the relying party. See Figures 3 and 4 and Table 3. 

A PKI is comprised of technical, process and people components that must harmonize into an effective 
infrastructure. As with any infrastructure, the business requirements must be initially determined. These 
requirements may be met by the deployment of a PKI. 

5.3 Business requirement impact on PKI environment 

5.3.1 General 

This clause uses business scenarios to illustrate the key differences between the closed, open and 
contractual environments. Tables 1 to 3 describe typical business scenarios, sample (security) requirements, 
and the associated PKI operations that would be performed if PKI was utilized to address the requirements. 

5.3.2 Illustration of certificate application in a closed environment 

This subclause describes several scenarios where the financial institution may use PKI for internal purposes 
and to support its services and communications internally or to its customers. 



1) An entity adhering to a trust service may act as a relying party or subscriber for certificates for itself or on behalf of 
other certificate subjects. In this case, subscribers and certificate subjects may be distinct entities bound by a business 
relationship which is outside the scope of this International Standard. 

10 
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Financial institution 



Certification autlnority 



Customer and/or staff 



Certificate subject 



Figure 1 — Two entities in a closed environment 



Table 1 — Certificate application scenarios in a closed environment 





Typical scenarios 


Sample requirements 


PKI operations 


1 


The financial institution (Fl) sends 
an e-mail to a customer (e.g. 
notification of deposit rate change). 


• Authentication of sender for 
recipient. 

• Message integrity for sender 
and recipient. 


• Sender creates digital signature. 

• Recipient validates sender's 
certificate. 

• Recipient verifies digital signature. 


2 


Exchange of sensitive e-mails 
between employees contained 
within the Fl's network boundaries. 


• Authentication of sender for 
recipient. 

• Message integrity for sender 
and recipient. 

• Confidentiality protection for 
message contents. 


• Recipient validates sender's 
certificate. 

• Sender creates digital signature. 

• Recipient verifies digital signature. 

• Sender fetches recipient's certificate 
from directory. 

• Sender encrypts message with 
recipient's public key. 

• Recipient decrypts message with 
recipient's private key. 


3 


Travelling sales force with Fl 
laptops need to exchange 
customer and sales information 
with centralized support systems. 


• Mutual authentication of 
employee by the Fl and server 
by employee. 

• Confidentiality protection for 
data. 


• Provision of employee identification 
certificates. 

• Provision of server ID certificate. 

• Invoke SSL encryption. 

• Invoke SSL encryption. 


4 


The internal network distribution of 
the Fl's software to customer 
facing devices (e.g. ATM software). 


• Proof that the software that is 
being loaded into the device 
comes from an authentic 
source. 


• Fl digitally signs software 
applications. 

• Recipient verifies digital signature 

• Recipient validates Fl's certificate. 


5 


Customer using a remote banking 
service where the server and 
browser application are provided 
by the Fl. 


• Mutual authentication of client 
(customer) by the Fl and 
server by customer software. 

• Confidentiality protection for 
customer data. 


• Customer authenticates to service 
using client certificate. 

• Server authenticates to customer 
using server certificate. 

• Invoke SSL encryption. 



11 



IS/ISO 21188: 2006 



5.3.3 Illustration of certificate application in a contractual environment 

This subclause describes tine financial institution using the PKI for support transactions to its customers within 
a scheme or where a contract with rules has been established between the parties. It will provide either 
certificate issuance or certificate validation services, or both services, to its customers. 



Fl#1 



Fl#2 



Certification authority 




Certificate validation 
service provider 


Customer 

1 


i 
1 




Customer 






Relying party 









Figure 2 — Four entities in a contractual environment 



Table 2 — Certificate application scenarios in a contractual environment 





Typical scenario 


Sample requirements 


PKI operations 


1 


Fl employee sends an e-mail via 
the Internet to a customer that uses 
another TSP. 


• Authentication of sender for 
recipient. 

• Message integrity. 

• Confidentiality protection for 
message contents. 


• Recipient validates sender's 
certificate. 

• Customer checks digital signature. 

• Sender fetches recipient's certificate 
from directory. 

• Sender encrypts message using 
recipient's public key. 

• Recipient decrypts message using 
recipient's private key. 


2 


Customer submits a purchase 
order to a merchant. 


• Customer authorizes purchase 
order. 

• Authentication of customer by 
merchant. 

• Transaction message integrity. 


• Customer digitally signs purchase 
order using certificate demonstrating 
mandated authority. 

• Recipient validates sender's 
certificate. 

• Merchant verifies digital signature. 


3 


Customer receives invoice from 
merchant. 


• Message authentication. 


• Check digital signature and validate 
certificate. 


4 


An existing customer using an 
e-banking service to send high 
value payment instructions to Fl. 


• Strong mutual authentication. 

• Message integrity. 

• Confidentiality. 


• Customer validates Fl's server 
certificate. 

• Fl validates customer's certificate. 

• Fl verifies digital signature. 

• Sender fetches recipient's certificate 
from directory. 

• Sender encrypts message using 
recipient's public key. 

• Recipient decrypts message using 
recipient's private key. 
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Table 2 (continued) 





Typical scenario 


Sample requirements 


PKI operations 


5 


Corporate customer sends 
payment files directly to an 
automated clearing house. 


• Authentication of sender 
(account holder) for recipient. 

• Message integrity and non- 
repudiation proof. 

• Confidentiality protection for 
message contents. 

• Dual customer authorization. 


• Clearing house validates customer's 
certificate. 

• Clearing house verifies digital 
signature. 

• Customer fetches clearing house's 
certificate from directory. 

• Sender encrypts message using 
recipient's public key. 

• Recipient decrypts message using 
recipient's private key. 

• Two individuals digitally sign the 
payment files. 

• Clearing house verifies both digital 
signatures. 


6 


EMV purchase by a cardholder at 
point of sale. 


• Authentication of ICC by 
terminal off-line. 


• ICC creates digital signature. 

• Terminal checks ICC authenticity 
using ICC issuer public key certified 
by scheme CA. 



5.3.4 Illustration of certificate application in an open environment 

This subclause describes the financial institution's possible use of PKI to enable open external communication 
for itself, its own customers and external trading partners. The financial institution may offer trust services to 
its customers. 



Fl 



Certificate validation 
service provider 


( 


i 

Customer 


r 










J l^aiiy 



Figure 3 — Fl acting as certificate validation service provider in an open environment 
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Fl 



Certificate issuer 



Customer 



Certificate subject 



Figure 4 — Fl acting as certificate issuer in an open environment 



Table 3 — Certificate application scenarios in an open environment 





Scenario 


Sample requirements 


PKI operations 


1 


Web site visitor downloads 
executable code while browsing a 
financial institution's Web site. 


• Authentication of Fl. 

• Integrity of Fl executable code. 


• User validates Fl's certificate. 

• User verifies Fl's digital signature. 


2 


A customer visits an Fl Web site. 


• Authentication of an official Fl 
Web site (i.e., not spoofed). 


• User validates Fl's server certificate. 


3 


Exchange of e-mails between two 
employees from different FIs via 
the Internet where there is no 
formal agreement in place. 


• Authentication of sender for 
recipient. 

• Message integrity and non- 
repudiation proof. 

• Confidentiality protection for 
message contents. 


• Each Fl employee validates the 
sender's certificate. 

• Each Fl employee verifies digital 
signature. 

• Each Fl employee fetches recipient's 
certificate from directory. 


4 


An important electronic document 
(e.g. financial results) is published. 


• Authentication of source and 
integrity of content. 


• The user validates the Fl's 
certificate. 

• The user verifies the digital 
signature. 


5 


Exchange of sensitive e-mails 
between two customers using 
different TSPs. 


• Authentication of sender for 
recipient. 

• Message integrity. 

• Confidentiality protection for 
message contents. 


• Each customer validates the 
sender's certificate. 

• Each customer verifies the digital 
signature on the message received. 

• Each customer fetches the 
recipient's certificate from the 
directory. 



5.4 Functional perspectives 

PKI may be viewed from a number of different perspectives. Tine inardware, software and security procedures 
provide a ricin set of PKI functions tinat can be logically grouped into PKI roles that are specified below. The 
subclauses that follow describe the policy authority (a), the components of a certification authority (b to g), 
subjects (h) and relying parties (i). A typical allocation of functions to roles is provided below though specific 
functions may be undertaken by different roles. Multiple roles may be undertaken by the same organization. 

Figure 5 is a high-level representation of the functional elements within a PKI and their relationships. 
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Figure 5 — Policy authority, certification authority and end-user relationships 



The term "certification autlnority" is used in tliis International Standard to reflect the aggregate of the following 
PKI roles specified above, including: certificate issuer, certificate manufacturer, registration authority, 
repository, certificate validation service provider, and subject cryptographic mechanism provider. The policy 
authority is ultimately responsible for the effectiveness of the controls, management and operations of the CAs 
authorized to issue certificates under its certificate policies. The controls that the CA uses are defined within 
its certification practice statement. 

a) Policy authority (PA) performs the following management functions: 

— creates, maintains and approves the certificate policies; 

— specifies the content of public key certificates as described by a certificate policy; 

— distributes and promotes certificate policies; 
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— interprets adherence to its certificate poiicies; 

— autlnorizes parties to act as certification autlnorities under tine certificate poiicies; 

— approves certification practice statements for autlnorized CAs; 

— resoives or causes resoiution of disputes reiated to certificate poiicies; 

— ensures reguiatory compiiance; 

— ensures tinat tlie provisions of tlie CP remain valid witln regard to potential security tiireats; 

— receives and reviews reports of CA security incidents and actions tal<en; 

— approves and documents witlnin tlie CP tine procedures for revocation of certificates, including: 

— wino may submit revocation requests and reports; 

— how they may be submitted; 

— any requirements for subsequent confirmation of revocation reports and requests; 

— whether and for what reasons certificates may be suspended; 

— the mechanism used for distributing revocation status information; 

— specifies the maximum delay between receipt of a revocation request or report and the change to the 
revocation status information available to all relying parties based on a risl< analysis. 

b) Certificate issuer (CI) performs the following management functions: 

— manages the processes for issuing public key certificates; 

— issues and manages certificate status; 

— enters into a contractual arrangement with a subscriber under a subscriber agreement or banl<ing terms 
and conditions; 

— issues certificates to certificate subjects under one or more certificate policies; 

— provides a means for subjects or, where applicable, subscribers to request revocation; 

— arranges and manages the processes to revoke public key certificates; 

— owns and controls its signing key(s) and therefore can switch certificate manufacturers; 

— maintains ownership and control of its business records; 

— subscribes to a CPS; 

— processes upon receipt requests and reports relating to revocation; 

— authenticates source for requests and reports of certificate revocation (i.e., checked to be from an 
authorized source); 

— notifies the subject and, where applicable, the subscriber of a revoked or suspended certificate; 
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— provides directly or approves of tine mecinanisms of performing cryptograplnic signing and, winere 
appiicabie, decipinermentfunctionaiity, underline terms of tine certificate poiicy; 

— manages tine obligations and liabilities as stated in the CP. 

c) Certificate manufacturer (CM) performs the following CA operational functions: 

— creates and maintains its own CPS; 

— operates within the bounds of its CPS; 

— generates and distributes public key certificates; 

— generates and manages certificate signature asymmetric key pairs consistent with the specifications 
provided by a certificate issuer; 

— distributes the certificate issuer's public key(s) certificates; 

— generates information on certificate status (such as CRLs); 

— provides out-of-band notifications of certificate issuance and revocation where required; 

— maintains separation between different hosted certificate issuers; 

— maintains security, availability and continuity of the certificate signing function as specified in its CPS; 

— periodically demonstrates audited compliance with the certification authority control objectives specified in 
Clause 7; 

— ensures regulatory compliance; 

— ensures that the provisions of the CPS remain valid with regard to potential security threats; 

— optionally generates subscriber key pairs at the request of the RA where permitted by the CP. 

d) Registration authiority (RA) performs the following operational functions: 

— manages a public key certification request from a subject or, where applicable, a subscriber; 

— manages the distribution of subscriber key pairs where the CM has generated the key pairs as permitted 
bytheCP; 

— performs the registration process by: 

— checking the subject's credentials evidencing claimed identity in line with regulatory know-your- 
customer requirements (e.g., money-laundering requirements); 

— verifying that identifying data provided by the certificate subject is valid; 

— verifying that the identifying data pertain to the certificate subject; 

— verifying that the certificate subject is entitled to obtain a public key certificate under the certificate 
policy; 

— verifying that the certificate subject possesses the asymmetric private key corresponding to the 
public key; 
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— manages the submission of certificate requests to tine certificate manufacturer; 

— records tine binding of tine certificate subject's identification data to tine certificate subject's public key; 

— receives and processes certificate subject or, where applicable, subscriber requests to revoke certificates, 
suspend certificates and reinstate suspended certificates; 

— operates within the bounds of the applicable certificate policies and where applicable the CM's CPS. 

e) Repository performs the following technological functions: 

— stores and distributes public key certificates; 

— stores and distributes information on certificate status (such as CRLs and/or online certificate status); 

— stores and distributes PKI public information (e.g., certificate policy). 

f) Certificate validation service provider (CVSP) performs the following functions: 

— enters into a contractual arrangement with the relying PARTY, and when undertaken formally, parties 
sign a relying party agreement; 

— enters into a contractual arrangement with the policy authority to collect information on the certificate 
policies and update the status of the associated certificates; 

— operates within the bounds of its own organizational policies and applicable certificate policies; 

— maintains the status of certificates where the CVSP holds certificates on behalf of other trust service 
providers in accordance with the certificate policy; 

— seeks to obtain the current status on certificates from other trust service providers; 

— validates the status of a certificate and provides a response to the requestor. 

g) Subject cryptoqrapliic mechianism provider (SCIVIP) performs the following function: 

— supplies a mechanism that consists of a physically secure-signature-creation device (e.g. an ICC) or 
alternatively a software emulation that provides comparable functionality in order to: 

— securely store the subject's private key and associated certificates; 

— enable secure activation and deactivation of the private key; 

— provide a secure initial activation mechanism. 

h) Subject or, wliere applicable, subscriber (S) performs the following functions: 

— presents their credentials as evidence for claimed identity in accordance with the relevant certificate 
policy; 

— generates or causes to be generated one or more asymmetric key pairs; 

— presents the public key certification request to the registration authority; 

— complies with the asymmetric private key protection requirements (i.e., key storage and cardholder 
verification); 

— reports loss or compromise of private key(s) and inaccuracy of certificate information; 
18 
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— uses their key pair(s) in conjunction witin autlnorized business appiications in compiiance witin appiicabie 
poiicies and in accordance witin tine CP; 

— uses tineir own private l<ey (signing) to cryptograplnicaiiy sign message digests or simiiar data eiements; 

— uses tineir own private l<ey (encipinerment) to decrypt messages. 
i) Relying party (RP) performs tine foiiowing functions: 

— vaiidates subject pubiic key certificates or requests tine vaiidation of certificate subject pubiic key 
certificates tinrougin a CVSP; 

— uses tine pubiic key in tine subject's certificate for autinorized business appiications and appropriate 
cryptograplnic functions (e.g. digitai signature verification, key exclnange, etc.) in compiiance with 
appiicabie poiicies and in accordance with the CP; 

— uses the subject's pubiic key to check the validity of the digitai signature; 

— uses the subject's pubiic key (confidentiality) and appropriate cryptographic mechanism to encipher 
messages to provide confidentiality protection (optional). 

It is possible for any or all of the certification authority roles to be delegated to one or more third party 
organizations, either directly or indirectly; nevertheless, it is the responsibility and liability of the certificate 
issuer to manage the associated CP risks. 

5.5 Business perspectives 

5.5.1 General 

A financial institution's future ability to participate in an on-line global economy depends on the existence of a 
trusted and secure environment in which to conduct business in the electronic medium. The ideal goal of any 
financial institution is to establish a security infrastructure for an on-line marketplace that will allow it an 
opportunity to support internal security needs, to enhance and service its customer base as well as to enter 
new markets for the provision of trust services. In defining the business operations of the financial institution, 
many issues will be addressed, including the consideration of 5.5.2 to 5.5.7. 

5.5.2 Business risks 

There is a business need to manage risks in conducting electronic commerce. PKI is one such control 
mechanism that may provide appropriate protection to manage those risks. PKI is a control mechanism that 
may be used for many different applications and can be seen as a common, re-usable infrastructure. 

5.5.3 Applicability 

The parties involved must determine whether the certificate policy is appropriate to the business application 
and associated risks. 

5.5.4 Legal issues 

The legal perspective considers the public key certificate as an assertion or a series of assertions made by the 
certification authority about the subject to the relying party. The CP (perhaps augmented by the CPS) 
establishes what assertions the certification authority is making. It may also specify what warranties the 
certification authority offers, that these assertions are true, and what liabilities will be assumed or allocated by 
the certification authority in the event that an assertion is untrue. It may specify any limitations to these 
liabilities, such as specifying a group whose members are the only parties permitted to act as relying parties. It 
may specify the maximum liabilities per certificate or per transaction, and specifies the types of transaction in 
which the warranties are in effect. It specifies procedures for submission of claims and for resolution of 
disputes. It specifies any conditions a relying party should fulfil or actions a relying party should perform before 
being authorized to rely on a certificate and its assertions. 
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The responsibilities and iiabiiities reiating to a PKI, particuiariy winere different businesses are involved, are 
commoniy a major issue for a contractual PKI environment. The responsibility for and scale of commercial 
liability will be a significant factor in setting out the business requirements, especially for trust services. 

5.5.5 Regulatory issues 

The regulatory perspective considers differences in the acceptability of PKI processes and services in the 
conduct of business related in alternative jurisdiction, industry standards and/or industry audit functions. 

5.5.6 Business usage issues 

Business usage, as described in 5.3, is between the entities defined in the environment (i.e., the certificate 
subject or, where applicable, the subscriber and the relying party). Both parties must fulfil their obligations set 
forth in the CP or the agreement that defines these obligations. The certificate subject or, where applicable, 
the subscriber may then use the digital signature process to authorize a message or transaction and 
subsequently the relying party may then rely upon the authenticated signature. 

Optionally, under a warranty scheme, a reliance limit may be established by the CP or by separate agreement. 
Where this is the case, the relying party may choose to seek a guarantee for that transaction, up to a specific 
limit. 

5.5.7 Interoperability issues 

The disparate business practices and related policies are often a further challenge in an open PKI 
environment from business and technological perspectives. However, in a contractual PKI environment, rules 
of operation are established specifically to overcome interoperability issues. In a closed environment, where 
the certificate issuer and the relying party are the same financial institution, it is up to that organization to 
resolve any interoperability issues. The disparate policies regarding use of the PKI need to be considered in 
setting out the business requirements for trust services. 

The interoperability of trust services for financial institutions requires a governance framework that addresses 
the issues of: 

— legal jurisdiction and responsibilities; 

— commercial risk management considerations; 

— technical recognition of the certificate and operational processing aspects; 

— policy and trust scheme obligations. 

Non-technical interoperability issues are resolved by adherence and by conformance to the contractual rules 
of the environment that describe the business contract responsibilities and liabilities according to the business 
application under the certificate policy interpretation. 

The detailed CPS by itself does not form a suitable basis for interoperability between CAs operated by one or 
by different organizations. Rather, certificate policies best serve as the vehicle on which to base common 
interoperability standards, certificate requirements and common assurance criteria for an industry or global 
basis. 

A CA with a single CPS may support multiple certificate policies (e.g. used for different application purposes 
and/or by different certificate user communities). In addition, different CAs, with non-identical certification 
practice statements, may support the same CP. 

a) A CP may apply more broadly than to just a single organizational unit or single organization. If a particular 
CP is widely recognized, it has great potential as the basis of automated certificate acceptance in many 
systems. 
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b) Financial institutions tinat operate pubiic or inter-organizationai certification autlnorities sinaii document 
tineir own practices in CPSs. Tine CPS is one of the organization's means of protecting itself and 
positioning its relationships with subscribers and other entities. 

c) Technical implementation may differ due to interpretation of standards and protocols by the PKI 
integrators. A technical comparison must take place within the PKI environment to ensure technical 
interoperability. 

For interoperability of PKIs operated by different CAs there is a need for a trusted path to enable a relying 
party to verify the certificates issued by another CA. This trusted path can be provided by one CA issuing a 
cross-certificate to another. This may even involve other third party CAs that assist in providing a trusted path 
through a chain of cross-certificates. Care needs to be taken in the policy implications of such cross- 
certificates and in particular that the implied trust relationship is matched by an appropriate business 
relationship. 

CAs may be organized in a hierarchy with a "root" CA that is trusted by all relying parties to issue "CA" 
certificates for subordinate CAs. Special attention needs to be paid to the security controls applied to such 
root CAs since the impact of any successful attacks on such root CAs can be very significant. Furthermore, 
the needs for some areas of the policies and practices of such a root CA with regards to functions such as 
registration are likely to significantly differ. 

Where interoperability is required or anticipated between PKIs operated by different CAs under different 
certificate policies, either: 

— relying parties operating under one PKI must accept policies used by its own CA and that of the another 
CA; 

or 

— there must be a recognized equivalence mapping from the policy used by the external CA to that used by 
the relying party's own CA; this equivalence mapping needs to be established by the relying party's CA to 
provide a one-way mapping to the external policy, however, in practice, mutual equivalence is established 
between CAs by bilateral agreement. 

5.6 Certificate policy (CP) 

5.6.1 General 

A CP is a common set of rules with regard to the level of trust that shall be met by associated certificates used 
for a particular purpose. The CP also specifies the criteria that shall be agreed upon and complied with by a 
certification authority before certificates issued by such a certification authority may be accepted by a relying 
party. It is developed by a policy authority. The policy authority writing the CP may range from a single 
business entity to a collection of entities such as a payment association established to interchange 
transactions between the member entities. 

As an example, a company wishing to transact with another company may require for business reasons the 
use of digitally signed messages. Each party would need to define their business requirements and adopt a 
certificate policy that meets those requirements. Both parties need to obtain a certificate from a certification 
authority that supports that certificate policy. 

The purpose of a CP includes: 

— to define and limit the use of certificates; 

— to specify requirements and obligations of certificate subject and, where applicable, subscriber, the 
certification authority and relying parties; 

— to define liabilities for certificate subject and, where applicable, subscriber, the certification authority and 
relying parties; 
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— to specify policy administration process; 

— to specify governing iaw. 

A CP sinaii be represented by a unique registered object identifier winicin needs to be recognized by members 
of tine contractual environment. Tine PAtinat registers tine object identifier also publishes a textual specification 
of the CP, for examination by certificate users. (See Annex C for additional information.) 

The CP focuses on what the certificate is to be used for and is defined independently of the details of the 
specific operating environment of a certification authority. 

5.6.2 Certificate policy usage 

Certificate policies are created for specific purposes within a PKI and business environment. There may be 
many certificate policies within one root hierarchy, each defining the business/policy requirements for groups 
of certificates sharing common policy requirements. In each case, the policy authority must develop the 
specific certificate policy and ensure that the certificate practices statement of the certification authority 
creating the certificates adequately address the requirements of each certificate policy. 

Examples of different certificate policy usage would include but not be limited to: 

a) certificate policy for specific functional applications (e.g. server identification certificate for customer to 
authenticate their on-line banking service provider); 

b) subscription to the certificate policy that matches the business application (e.g. customer signing a 
purchasing order from a merchant); 

c) subscription to the certificate policy that matches a generic security application with a defined 
environment within prespecified restrictions, (e.g. providing confidentiality protection on all message types 
to certificate subject across the Internet). 

5.6.3 Certificate policies within a hierarchy of trust 

PKIs are commonly structured into a hierarchy with the top or apex of the hierarchy being a root. The root 
delegates a portion of its trust to subordinate CAs based upon the organizational needs. The root and 
intermediate levels primarily authenticate and sign the digital certificates of subordinate levels and provide the 
structuring of business requirements by differentiating between organizational needs (e.g. between 
geopolitical or organizational regions, countries or states, organizational units, etc.). As illustrated in Clause 6, 
the hierarchies permit the use of multiple certificate policies, each defining the different business requirements 
of facets of the business environment. With a hierarchy, each level is more granular or homogenous in its 
specificity of requirements to a "smaller" group of certificates issued to end-entities. Each group of certificate 
end-entities share a common set of certificate policies. 

For example, the root level at the highest level of the hierarchy, by definition must use a self-signed certificate 
and may only be used to sign subordinate certificates. A subordinate CA must be defined based upon 
geopolitical, organizational or other requirements. The subordinate CAs must cascade into multiple levels 
based upon multiple structural needs or it may issue certificates to end-entities. 

In a hierarchy, the root must be the most trusted point. Each subordinate level shares the trust between their 
peers, but each must trust the superior point from which they have been delegated responsibility. 

Examples of different certificate policy usage include but are not limited to: 

a) certificate policy for identifying the root CA with its implied self-signed certificate (certificates issued under 
Policy A in Figure 6); 

b) certificate policy for identifying a subordinate CA established under the root CA or another subordinate 
CA. To sign the public keys of the subordinate or intermediate CAs, the root CA acting as the ultimate 
parent in the CA hierarchy in the Fl (certificates issued under Policy B in Figure 6). 

22 



IS/ISO 21188: 2006 



In Figure 6, the policy authority issues the root policy and all subordinate policies within the hierarchy of trust. 



(Root policy) 
Root CA 



(Policy A) 
Sub-CA 



(Policy B) 

Certificate issuing 

CA 



(Policy D) 
End entity 



(Policy E) 
End entity 



(Policy A) 

Certificate issuing 

CA 



(Policy C) 
End entity 



Figure 6 — Root liierarchy creates a liierarcliy of trust 

5.6.4 Certificate status 

A policy authority shall specify the conditions applicable to the states of a certificate issued under a specific 
CP. 

As defined in ISO 15782-1 , a certificate may be in one of the following states: 

a) live -operational; 

b) suspended (state called "on hold" in ISO 15782-1); 

c) revoked; 

d) expired. 

Once a certificate is revoked or expired it cannot return to a live state. Refer to ISO 15782-1 for further 
discussion of certificate management. 

The policy authority shall specify the conditions applicable to the states of a certificate issued under a specific 
CP. 

5.7 Certification practice statement (CPS) 

The certification practice statement describes the necessary and sufficient procedures and controls employed 
by the CA to meet the requirements of the certificate policies. 
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The purpose of the certification practice statement is to clearly define the CA's procedures and practices to 
manage the risks associated with certificate policies. A useful approach in completing the certification practice 
statement is to follow the outline provided in Annex B and clearly define the step-by-step practices from 
certificate request/issuance, certificate verification and required supporting functions. 

As indicated earlier, the CA is the entity responsible for performing the five roles of 1) registration, 
2) certificate manufacturer, 3) certificate issuer, 4) repository and 5) validation services. The CA is responsible 
for clearly defining the controls to accomplish these roles in meeting the requirements set forth in the CP. The 
controls are documented in the certification practice statement (CPS). The roles and functions of a CA may be 
securely delegated in any manner it desires, but all the roles and functions shall be completed and the CPS 
shall be written and maintained by the CA. 

A CPS may take the form of a declaration by the CA of the details of its trustworthy system and the practices it 
employs in its operations to securely issue and manage its certificates. Portions of a certification practice 
statement may also be part of the contract between the CA and the subscriber. When the legal relationship 
between a CA and subscriber is consensual, (e.g. in a case of a home banking relationship between a 
consumer or corporation and a bank), a contract, such as a subscriber or account agreement, would be a 
means of giving effect to the contents of the CPS. 

5.8 Relationship between certificate policy and certification practice statement 

5.8.1 General 

The roles of the certificate policy and certification practice statement are illustrated in 5.8.2 to 5.8.6. 

5.8.2 Authority 

A policy authority specifies the certificate policy that is adopted by the certification authorities that have their 
controls described in certification practice statements. ACP is created, maintained, distributed and interpreted 
by the policy authority. The policy authority may either represent one financial institution or be shared by a 
number of major stakeholders. A certification authority in support of its operation prepares a CPS or an 
equivalent document as evidence of its ability to comply with one or many certificate policies. A formal CPS is 
not compulsory in a contractual PKI environment and is often determined by either the rules of the community 
or the policy authority. In any event, the CA shall have documented its practices. While a simple compliance 
statement may suffice with a contractual PKI environment, a CPS, nevertheless, provides guidance for both 
internal processing and processing completed by delegated roles. 

5.8.3 Purpose 

The purpose of a certificate policy is to state "what is to be adhered to" by the CA, the subject and the relying 
parties, while a CPS states "how the certificate policy is adhered to" by the CA (i.e., the control processes the 
CA will use in creating and maintaining the digital certificate). The CP is included by reference in the digital 
certificate. The relationship between the CP and CPS is similar in nature to the relationship of other business 
policies that state the requirements of the business, while operational units define the practices and 
procedures of how these policies are to be carried out. 

5.8.4 Level of specificity 

A certificate policy is prescriptive. 

A certification practice statement is descriptive and detailed. Such documents are generally defined as internal 
operating procedure documents that may describe specific tasks and responsibilities within an organization. 
Such documentation may be used in the daily operation of the CA and reviewed by those performing a 
process review or audit. 
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5.8.5 Approach 

The CP is based upon known business requirements. 

A CPS is tailored to tine organizational structure, operating procedures, facilities and computing environment 
of a certification authority. 

5.8.6 Audience and access 

In general, the CP is managed as public information in the contractual environment, and therefore widely 
disseminated by the PA to all participants. The CP should clearly identify the distribution policy of public, 
sensitive and confidential information both within the contractual environment and to appropriate external 
parties. 

A CPS is a statement by a CA as to the control practices it will follow in issuing and maintaining certificates 
and clearly defines how its practices fully support the CP identified. It is therefore by its nature a sensitive 
document which may be considered confidential. If the circulation of the CPS is restricted, financial institutions 
may use a PKI Disclosure Statement, indicating the type and nature of the controls without disclosing specific 
control details to support the CP. 

For example, the CP may state that all certificate registration transactions are considered sensitive and for 
reasons of individual privacy, all such transactions will be protected during transmission and storage. The 
CPS may then further identify that all certificate registration transactions will be encrypted during transmission 
and list the business divisions that are allowed access to the stored information. The CPS may also specify 
the algorithms and key lengths used for encryption during transmission and the access control mechanism 
used for storage. The CA's confidential operating procedures, rather than the CP or CPS, would typically 
include more detailed information about the administration of the access control mechanisms. 

5.9 Agreements 

In order to formalize the relationships, there shall be a subscriber agreement between the certificate issuer 
and the subscriber. The subscriber agreement describes the terms and conditions of service provision and 
also binds the subscriber to its obligations specified in the certificate policy. The policy authority shall make 
the certificate policy available to the subscriber. 

There shall be a relying party agreement between the certificate validation service provider and the relying 
party. The policy authority shall make the certificate policy available to the relying party and the CVSP. 

Typically there will be no contract between the subscriber and the relying party. 

The CPS shall be made available by the certificate manufacturer to the certificate issuer and to the policy 
authority. Typically the CPS will not be made available to subscribers and relying parties or the CVSP. 
Typically, a PKI disclosure statement may be used for this purpose or alternatively an independent 
assessment may be used to determine the suitability of the controls described in the CPS. However, at its 
discretion, the certification authority may provide copies of its CPS to the CVSP. The contents of the PKI 
disclosure statement are determined at the discretion of the CA. 

When a PKI operates within a scheme, the scheme will typically specify requirements that should be met by 
entities within the PKI. The policy authority is responsible for ensuring that the CP complies with the scheme 
rules. For purposes of interoperability each respective CA's CPS or PKI disclosure statement may be made 
available to the respective CAs prior to cross-certification. 
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Figure 7 provides an overview of tine typicai controi documents witlnin tine standard financial PKI nnodel. 
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Figure 7 — Control documents within standard financial PKI model 



5.10 Time-stamping 

The timing of events from a trusted time source (i.e., a time source known to be synchronized with universal 
coordinated time (UTC) can be an important adjunct to the security services provided by a PKI. Not only is this 
necessary to place secured events within context (e.g. for dispute resolution) but also as a means of 
assurance of trust services. 

There are two aspects of certificate usage where timing is of particular importance. Firstly, trust services are 
based on certificates which have a validity period. If a certificate is used to protect data outside that period 
then the validity of the certificate cannot be assured. Secondly, if a certificate is revoked then any use of the 
certificate after the time that it is revoked may be considered to be invalid. Thus, if there may be a significant 
time between the application of a certificate in securing data and the checking of the validity of the protection, 
e.g. when applying a digital signature to stored data, it is important to be assured of the time at which the 
signature was applied. If it can be assured that a signature was created before the supporting certificate had 
expired or was revoked, then the validity of signature can be assured long after either of those events. It is for 
the relying party to determine whether they accept the risk associated with a certificate that may have expired 
or may have been revoked in the interim period. 

A method of providing assurance of the time that a signature was created is to employ a trusted third party, 
commonly called a time-stamping authority (TSA) to bind a time to the digital signature on or near the time 
that the signature was created. This technique is commonly called time-stamping. An example time-stamping 
protocol is defined in ISO 18014-2. This time-stamping protocol uses a hash digest of the data to be time- 
stamped (e.g. signed data) along with a trusted source of time digitally signed by the trusted authority. 

This time-stamping service may be used, for example, by the signatory immediately after signing or before 
being placed in long-term storage. Once time-stamped, the data can be assumed to be valid even if the 
supporting certificate subsequently expires or is revoked. Where data are to be archived over very long 
periods, for example beyond the validity period of TSA's own certificate, further time-stamps may be applied to 
ensure the ongoing protection of the signed data. 
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Such an application of time-stamping may also be used to protect a signatory "repudiating" a signature by 
subsequently claiming to have the signing key compromised and so causing the certificate to be revoked. If 
the signed data are time-stamped on or near the time that the signature was created it can be shown to be 
valid at that time even though the certificate may subsequently have been revoked. 

A variation of the time-stamping mechanism described above is to link together a time-stamp token with 
others previously issued by a time-stamping authority to provide greater assurance in the security of a single 
time-stamp (see ISO 18014-3). Another variation is to employ several independent time-stamping authorities 
and so avoid dependence on a single trusted authority. 



6 Certificate policy and certification practice statement requirements 

6.1 Certificate policy (CP) 

Certificates shall be issued under at least one CP. A certificate issued in the X509 v3 format shall be explicitly 
associated with one or more certificate policies as defined in 8.2.6 of ISO 15782-1:2003. 

a) CP shall describe the conditions for applicability of the certificates issued by the CA, including: 

— specific permitted uses for the certificates if such use is limited to specific applications; 

— limitations on the use of certificates if there are specified prohibited uses for such certificates. 

b) CP shall in accordance: 

— be uniquely identified; 

— contain its name; 

— identify where the document may be acquired (e.g. URL, e-mail address, OID, etc.). 

c) CP shall provide a definition of terms used within the policy (where such definitions differ from those 
defined in Clause 3). 

d) CP shall provide procedures for administration. CP shall include administrative procedures in order to: 

— identify policy authority; 

— identify procedures for publication, change and subsequent notification; 

— identify the version number and effective date; 

— include an expiry date if applicable. 

e) CP shall include disclosure of governing law or how the governing law is determined. 

f) CP shall identify subscriber obligations and liabilities. CP should include subscriber obligations and 
liabilities in order to: 

— provide information in certificate request that is accurate and that the act of accepting the certificate 
guarantees that information contained is accurate; 

— guarantee that if the subscriber or the certificate subject generates the public key pairs, it will be 
done in a manner appropriate to the control objectives specified (see 8.3.4); 

— protect the access to the private key associated with certificate; 
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— notify the issuer of private key compromise or cinange of status witinin tine time frame specified in tine 
CP; 

— restrict tine use of tine certificate to the usage specified. 

g) CP shall identify issuer obligations and liabilities. CP should include issuer obligations and liabilities in 
order to: 

— notify the subject and, where applicable, the subscriber of the certificate that the certificate has been 
issued; 

— notify the subject and, where applicable, the subscriber whose certificate has been revoked, 
suspended or unsuspended; 

— make available to relying parties the certificate status in accordance with the CP (i.e., by posting 
certificate status information in a repository available to participating subscribers and relying parties); 

— comply with the CP identified and its associated certification practice statement; 

— provide notification of any disclaimers of liability (e.g. for misuse of certificate for disallowed 
applications); 

— provide confidentiality protection to non-public subscriber and relying party information. 

h) CP shall identify relying party obligations and liabilities. CP should include relying party obligations and 
liabilities in order to: 

— restrict usage to applications identified; 

— provide notification regarding any disallowance of claims of liability for misuse of the certificate on 
excluded applications; 

— check digital signature; 

— validate certificate content and status; 

— provide notification of applicable liability caps and warranties. 

1) CP should identify any applicable reliance or financial limits for certificate usage, 
j) CP shall state the minimum requirements for: 

— subscriber identification and authentication; 

— certificate status publication; 

— subscriber private key protection; 

— CA private key protection. 

k) CP shall state the minimum requirements for the mandatory X.509 v3 fields: 

— version number; 

— serial number; 

— signature algorithm; 
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— issuer; 

— valid from and valid to dates; 

— subject; 

— public key aigoritlnm and minimum key length; 

— required extensions. 

See Annex A for additional information on certificate policies. 

6.2 Certification practice statement (CPS) 

a) A certification authority shall document its certification practices. 

b) A CPS or equivalent shall support each CP under which the CA issues or manufactures certificates. 

c) The CA's certification practices shall address the contents provided in Annex B that include the following 
high-level components to the level of detail required by the policy authority with reference to the relevant 
certificate policies: 

1) introduction; 

2) general provisions; 

3) identification and authentication; 

4) operational requirements; 

5) physical, procedural and personnel security controls; 

6) technical security controls; 

7) certificate and CRL profiles; 

8) practices administration. 

d) A CA's certification practices shall comply with the control objectives specified in Clause 7. 

e) A CA's certification practices should include those control procedures specified in Clause 8, which are 
appropriate based on the CA's assessment of risks and meets the requirements of the supported 
certificate policies. 

See Annex B for additional information on certification practice statements. 

7 Certification authority control objectives 

7.1 General 

Control objectives in the areas of CA environmental controls, CA key life cycle management controls, and 
certificate life cycle management controls are presented in 7.2 to 7.6, representing baseline control criteria 
with which a CA shall comply and against which a CA may be evaluated or audited. Such an evaluation may 
take the form of an internal audit or external audit using any appropriate audit methodology as may be defined 
by the rules of the contractual environment. 
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A number of the control objectives are regarded as optional and would only be applicable if supported by the 
CA. These include: 

— CA-provided subject key generation services; 

— CA-provided subject key storage, recovery and escrow services; 

— integrated circuit card (ICC) life cycle management; 

— certificate renewal; 

— certificate suspension. 

7.2 CA environmental control objectives 

7.2.1 Certification practice statement and certificate policy management 

Control objectives: the CA shall maintain controls to provide reasonable assurance that its certification 
practice statement (CPS) and certificate policy (CP) management processes are effective. The policy authority 
(PA) shall have the responsibility of defining the business requirements and policies for using digital 
certificates and is specified in a certificate policy (CP) and supporting agreements. 

See 8.2.1 for control procedures to be considered for these control objectives. 

7.2.2 Security management 

Control objectives: the CA shall maintain controls to provide reasonable assurance that: 

— security is planned, managed and supported within the organization; 

— identified risks are managed effectively; 

— the security of CA facilities, systems and information assets accessed by third parties is maintained; 

— the security of information is maintained when the responsibility for CA sub-functions has been 
outsourced to another organization or entity. 

See 8.2.2 for control procedures to be considered for these control objectives. Guidance on security 
management may be found in ISO/IEC 17799. 

7.2.3 Asset classification and management 

Control objective: the CA shall maintain controls to provide reasonable assurance that CA assets and 
information receive an appropriate level of protection based upon the requirements of all supported certificate 
policies and risk analysis. 

See 8.2.3 for control procedures to be considered for this control objective. 

7.2.4 Personnel security 

Control objective: the CA shall provide reasonable assurance that personnel and employment practices 
enhance and support the trustworthiness of the CA's operations. 

See 8.2.4 for control procedures to be considered for this control objective. 
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7.2.5 Physical and environmental security 

Control objectives: the CA shall maintain controls to provide reasonable assurance that: 

— physical access to CA facilities is limited to authorized individuals; 

— CA facilities are protected from environmental hazards; 

— loss, damage or compromise of assets and interruption to business activities are prevented; 

— compromise of information and information processing facilities is prevented. 
See 8.2.5 for control procedures to be considered for these control objectives. 

7.2.6 Operations management 

Control objectives: the CA shall maintain controls to provide reasonable assurance that: 

— the correct and secure operation of CA information processing facilities is ensured; 

— the risk of CA systems failure is minimized; 

— the integrity of CA systems and information is protected against viruses and malicious software; 

— damage from security incidents and malfunctions is minimized through the use of incident reporting and 
response procedures; 

— media are securely handled to protect them from damage, theft and unauthorized access. 
See 8.2.6 for control procedures to be considered for these control objectives. 

7.2.7 System access management 

Control objectives: the CA shall maintain controls to provide reasonable assurance that CA system access is 
limited to authorized individuals. Such controls shall provide reasonable assurance that: 

— operating system access is limited to authorized individuals with predetermined tasl< privileges; 

— access to network segments housing CA systems is limited to authorized individuals, applications and 
services; 

— CA application use is limited to authorized individuals. 

See 8.2.7 for control procedures to be considered for these control objectives. 

7.2.8 Systems development and maintenance 

Control objective: the CA shall maintain controls to provide reasonable assurance that CA systems 
development and maintenance activities are authorized to maintain CA system integrity. 

See 8.2.8 for control procedures to be considered for this control objective. 
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7.2.9 Business continuity management 

Control objectives: the CA shall maintain controls to provide reasonable assurance of continuity of operations 
in the event of a disaster. Such controls shall include at a minimum: 

— the development and testing of a CA disaster recovery plan; 

— the storage of required cryptographic materials (i.e., secure cryptographic device and activation materials) 
at an alternate location; 

— the storage of back-ups of systems, data and configuration information at an alternate location; 

— the availability of an alternate site, equipment and connectivity to enable recovery. 

The CA shall maintain controls to provide reasonable assurance that potential disruptions to subscribers and 
relying parties are minimized as a result of the cessation or degradation of the CA's services. 

See 8.2.9 for control procedures to be considered for these control objectives. 

7.2.10 Monitoring and compliance 

Control objectives: the CA shall maintain controls to provide reasonable assurance that: 

— it conforms with the relevant legal, regulatory and contractual requirements; 

— compliance with the CA's security policies and procedures is ensured; 

— unauthorized CA system usage is detected. 

See 8.2.10 for control procedures to be considered for these control objectives. 

7.2.11 Audit logging 

Control objectives: the CA shall maintain controls to provide reasonable assurance that: 

— CA environmental, key management and certificate management events are accurately and appropriately 
logged; 

— the confidentiality and integrity of current and archived audit logs are maintained; 

— audit logs are completely and confidentially archived in accordance with disclosed business practices; 

— audit logs are reviewed periodically by authorized personnel. 

See 8.2. 11 for control procedures to be considered for these control objectives. 

7.3 CA key life cycle management control objectives 
7.3.1 CA key generation 

Control objective: the CA shall maintain controls to provide reasonable assurance that CA key pairs are 
generated in accordance with defined key generation ceremony scripts and the requirements of the CPS. 

See 8.3.1 for control procedures to be considered for this control objective. 
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7.3.2 CA key storage, back-up and recovery 

Control objectives: the CA shall maintain controls to provide reasonable assurance that: 

— CA private keys remain confidential and maintain their integrity; 

— access to CA cryptographic hardware is limited to authorized individuals. 
See 8.3.2 for control procedures to be considered for these control objectives. 

7.3.3 CA public key distribution 

Control objective: the CA shall maintain controls to provide reasonable assurance that the integrity and 
authenticity of the CA public l<ey and any associated parameters are maintained during initial and subsequent 
distribution. 

See 8.3.3 for control procedures to be considered for this control objective. 

7.3.4 CA key usage 

Control objective: the CA shall maintain controls to provide reasonable assurance that CA keys are used only 
for their intended functions in their predetermined locations. 

See 8.3.4 for control procedures to be considered for this control objective. 

7.3.5 CA key arcliival and destruction 

Control objectives: the CA shall maintain controls to provide reasonable assurance that: 

— archived CA keys remain confidential and secured in the event that they are put back into production; 

— CA keys are completely destroyed at the end of the key pair life cycle as determined by the CPS. 
See 8.3.5 for control procedures to be considered for these control objectives. 

7.3.6 CA key compromise 

Control objective: the CA shall maintain controls to provide reasonable assurance that continuity of operations 
is maintained in the event of the compromise of the CA's private keys. 

See 8.3.6 for control procedures to be considered for this control objective. 
7.4 Subject key life cycle management control objectives 

7.4.1 CA-provided subject key generation services (if supported) 

Control objectives: if the CA provides subscriber key management services, the CA shall maintain controls to 
provide reasonable assurance that: 

— subject keys generated by the CA (or RA or card bureau) are generated in accordance with the CP; 

— subject keys generated by the CA (or RA or card bureau) are securely distributed to the subject by the CA 
(or RA or card bureau). 

See 8.4.1 for control procedures to be considered for these control objectives. 
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7.4.2 CA-provided subject key storage, recovery and escrow services (if supported) 

Control objectives: if tine CA provides subject confidentiality key storage, recovery or escrow services, the CA 
shall maintain controls to provide reasonable assurance that: 

— subject private keys stored by the CA remain confidential and maintain their integrity; 

— subject private keys archived by the CA remain confidential; 

— subject private keys stored by the CA are completely destroyed at the end of the key pair life cycle; 

— subject private keys escrowed by the CA remain confidential. 

See 8.4.2 for control procedures to be considered for these control objectives. 

7.4.3 Integrated circuit card (ICC) life cycle management (if supported) 

Control objectives: if the CA (or RA) distributes subject key pairs and certificates using integrated circuit cards 
(ICCs), the CA (or RA) shall maintain controls to provide reasonable assurance that: 

— ICC procurement, preparation and personalization are securely controlled by the CA (or RA or card 
bureau); 

— ICC usage is enabled by the CA (or RA or card bureau) prior to ICC issuance; 

— ICCs are securely stored and distributed by the CA (or RA or card bureau); 

— ICCs are securely replaced by the CA (or RA or card bureau); 

— ICCs returned to the CA (or RA or card bureau) are securely terminated. 
See 8.4.3 for control procedures to be considered for these control objectives. 

7.4.4 Requirements for subject key management 

Control objective: the CA shall prescribe the means to securely manage subject keys throughout the key life 
cycle. 

See 8.4.4 for control procedures to be considered for this control objective. 
7.5 Certificate life cycle management control objectives 

7.5.1 Subject registration 

Control objectives: the CA shall maintain controls to provide reasonable assurance that: 

— subjects (or, where applicable, the subscribers) are accurately identified in accordance with the applicable 
"know-your-customer" requirements; 

— subjects' (or, where applicable, the subscribers') certificate requests are accurate, authorized and 
complete. 

See 8.5.1 for control procedures to be considered for these control objectives. 
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7.5.2 Certificate renewal (if supported) 

Control objective: if certificate renewai is supported under the CP, the CA shall maintain controls to provide 
reasonable assurance that certificate renewal requests are accurate, authorized and complete. 

See 8.5.2 for control procedures to be considered for this control objective. 

7.5.3 Certificate re-lcey 

Control objective: the CA shall maintain controls to provide reasonable assurance that certificate re-key 
requests are accurate, authorized and complete. 

See 8.5.3 for control procedures to be considered for this control objective. 

7.5.4 Certificate issuance 

Control objective: the CA shall maintain controls to provide reasonable assurance that certificates are 
generated (manufactured) and issued in accordance with the CP. 

See 8.5.4 for control procedures to be considered for this control objective. 

7.5.5 Certificate distribution 

Control objective: the CA shall maintain controls to provide reasonable assurance that, upon issuance, 
complete and accurate certificates are available to any entity as defined in the CP. 

See 8.5.5 for control procedures to be considered for this control objective. 

7.5.6 Certificate revocation 

Control objective: the CA shall maintain controls to provide reasonable assurance that certificates are revoked 
in a timely manner as dictated by risk, based on authorized and validated certificate revocation requests. 

See 8.5.6 for control procedures to be considered for this control objective. 

7.5.7 Certificate suspension (if supported) 

Control objective: if certificate suspension is supported, the CA shall maintain controls to provide reasonable 
assurance that certificates are suspended in a timely manner as dictated by risk, based on authorized and 
validated certificate suspension requests. 

See 8.5.7 for control procedures to be considered for this control objective. 

7.5.8 Certificate validation services 

Control objective: the CA shall maintain controls to provide reasonable assurance that timely, complete and 
accurate certificate status information (including certificate revocation lists and other certificate status 
mechanisms) is made available to end entities (subscribers and relying parties or their agents - i.e., CVSPs) 
in accordance with the CP. 

See 8.5.8 for control procedures to be considered for this control objective. 
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7.6 CA certificate life cycle management controls 

7.6.1 Subordinate CA certificate life cycle management 

Control objectives: the parent CA shall maintain controls to provide reasonable assurance that: 

— subordinate CA certificate requests are accurate, authenticated and approved; 

— subordinate CA certificate replacement (renewal and re-key) requests are accurate, authorized and 
complete; 

— new, renewed and re-keyed subordinate CA certificates are generated and issued in accordance with 
the CP; 

— upon issuance, complete and accurate subordinate CA certificates are available to end entities 
(subscribers and relying parties) in accordance with the CP; 

— subordinate CA certificates are revoked based on authorized and validated certificate revocation 
requests; 

— timely, complete and accurate certificate status information (including CRLs and other certificate status 
mechanisms) is made available to any entity as defined in the CP. 

See 8.6.1 for control procedures to be considered for these control objectives. 

8 Certification authority control procedures 

8.1 General 

The control procedures described in this clause represent recommended practices for business, operational, 
and technical use by a certification authority. Certain control procedures (i.e., control procedures using the 
word "shall") are required for compliance with this International Standard. 

A CA's CPS should contain only the control procedures that are appropriate based on the CA's assessment of 
risks in order to support the certificate policies under which certificates are issued. 

In assessing the CA's compliance with the CA control objectives and procedures, the reviewer should review 
the CA's CPS, supported certificate policies, other CA business practices disclosures, and other relevant CA 
documentation (e.g. CA operating procedures, security policies, network architecture diagrams and audit logs). 

Refer to 5.6.3 for a discussion of how to construct a CA hierarchy using certificate policies. For additional 
details regarding trust models, the reader should review Annex G of ISO 1 5782-1 :2003. 

8.2 CA environmental controls 

8.2.1 Certification practice statement and certificate policy management 



Control objectives: 



The CA shall maintain controls to provide reasonable assurance that its certification practice statement 
(CPS) and certificate policy (CP) management processes are effective. 

The policy authority (PA) shall have the responsibility of defining the business requirements and policies for 
using digital certificates and is specified in a certificate policy (CP) and supporting agreements. 



36 



IS/ISO 21188: 2006 



Control procedures: 



Policy authority (PA) management 



Tine PA sinould be responsible for ensuring that the CA's control processes, as stated in a certification 
practice statement (CPS) or equivalent, fully comply with the requirements of the CP. 



2 



The PA should have final authority and responsibility for specifying and approving certificate policy(ies). 



3 



The PA should have final authority and responsibility for approving the CA's certification practice 
statement (CPS). 



The PA shall ensure a certification practice statement (CPS) or equivalent document is in place at least 
describing the following: 

a) CA environmental controls; 

b) key life cycle management controls; 

c) certificate life cycle management controls. 



The PA or delegated representative should ensure the business service application is using the 
appropriate certificate policy. 



The PA should maintain procedures for the termination of certificate policies, notifying the affected 
parties. The PA shall notify, in the first instance, those CAs that support its certificate policies in order 
that appropriate actions may be undertaken expeditiously. 



The PA should maintain procedures in the event of its termination. In this event, affected parties shall 
be notified and the transference of relevant archived records to a custodian should take place. 



Certificate policies management 



8 



Certificate policy(ies) should be approved by the policy authority in accordance with a defined review 
process, including responsibilities for maintaining the certificate policy(ies). 



9 



A defined review process should exist to ensure that certificate policy(ies) are capable of support by the 
controls specified in the CPS. 



10 



The PA should make available the certificate policies supported by the CA to all appropriate subscribers 
and relying parties. 



11 



The CPS should contain an explanation of the controls to ensure compliance with: 

a) legislative requirements; 

b) contractual requirements; 

c) educational and notification requirements; 

d) prevention and detection of virus and other malicious software; 

e) business continuity requirements; 

f) escalation requirements from the consequences of security policy violations or security 
incidents. 



12 



The PA shall periodically conduct assessments to determine the adequacy of the CP to address 
business risks. 



Certification practice statement (CPS) management by CA 



13 



The CA's CPS should be approved by the PA and modified in accordance with a defined review 
process, including responsibilities for maintaining the CPS. 



14 



The CA should make available its certification practice statement (CPS) to all appropriate parties. 



15 



Revisions to the CA's CPS should be made available to appropriate parties. 



CA management 



16 The CA's controls shall be described in the CPS or equivalent documentation. 
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8.2.2 Security Management 



Control objectives: 



The CA shall maintain controls to provide reasonable assurance that: 

• security is planned, managed and supported within the organization; 

• identified risl<s are managed effectively; 

• the security of CA facilities, systems and information assets accessed by third parties is maintained; 

• the security of information is maintained when the responsibility for CA sub-functions has been 
outsourced to another organization or entity. 



Control procedures: 




Information security policy 


1 


An information security policy document, that includes physical, personnel, procedural and technical 
controls, should be approved by management, published and communicated to all employees. 


2 


The information security policy should include the following: 

a) a definition of information security, its overall objectives and scope and the importance of 
security as an enabling mechanism for information sharing; 

b) a statement of management intent, supporting the goals and principles of information security; 

c) an explanation of the security policies, principles, standards and compliance requirements of 
particular importance to the organization; 

d) a definition of general and specific responsibilities for information security management, 
including reporting security incidents; 

e) references to documentation that supports the policy. 


3 


There should be a defined review process for maintaining the information security policy, including 
responsibilities and review dates. 




Information security infrastructure 


4 


Senior management and/or a high-level management information security committee should have the 
responsibility of ensuring there is clear direction and management support to manage risks effectively. 


5 


A management group or security committee should exist to coordinate the implementation of 
information security controls and the management of risl<. 


6 


Responsibilities for the protection of individual assets and for carrying out specific security processes 
should be clearly defined. 


7 


A management authorization process for new information processing facilities should exist and be 
followed. 




Security of third party access 


8 


Procedures should exist and be followed to control physical and logical access to CA facilities and 
systems by third parties (e.g. on-site contractors, trading partners and joint ventures). 


9 


If there is a business need for the CA to allow third party access to CA facilities and systems, a risl< 
assessment should be performed to determine security implications and specific control requirements. 


10 


Arrangements involving third party access to CA facilities and systems should be based on a formal 
contract containing all necessary security requirements. 
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Control procedures: 



Outsourcing 



11 



If the CA outsources the management and control of all or some of its information systems, networks, 
and/or desktop environments, the security requirements of the CA should be addressed in a contract 
agreed between the parties. 



12 



If the CA chooses to delegate a portion of the CA roles and respective functions to another party, the 
CA should be ultimately responsible for the completion of the outsourced functions and the definition 
and maintenance of a statement of its CPS. 



8.2.3 Asset classification and management 



Control objective: 



The CA shall maintain controls to provide reasonable assurance that CA assets and information receive an 
appropriate level of protection based upon the requirements of all supported certificate policies and risk 
analysis. 



Control procedures: 



1 



Owners should be identified for all CA assets and assigned responsibility for the maintenance of 
appropriate controls. 



2 



Inventories of CA assets should be maintained. 



3 



The CA should have implemented information classification and associated protective controls for 
information based on business needs and the business impacts associated with such needs. 



Procedures should be defined to ensure that information labelling and handling is performed in 
accordance with the CA's information classification scheme. 



8.2.4 Personnel Security 



Control objective: 



The CA shall maintain controls to provide reasonable assurance that personnel and employment practices 
enhance and support the trustworthiness of the CA's operations. 



Control procedures: 



1 



The CA should employ personnel who possess the relevant skills, knowledge and experience 
appropriate for the job function. 



Security roles and responsibilities, as specified in the organization's security policy, should be 
documented in job descriptions. Trusted roles, on which the security of the CA's operation is 
dependent, should be clearly identified. 



Trusted roles shall at least include roles that involve the following responsibilities: 

a) overall responsibility for administering the implementation of the CA's security practices; 

b) approval of the generation, revocation and suspension of certificates; 

c) installation, configuration and maintenance of the CA systems; 

d) day-to-day operation of CA systems and system back-up and recovery; 

e) viewing and maintenance of CA system archives and audit logs; 

f) cryptographic key life cycle management functions (e.g. key component custodians); 

g) CA systems development. 
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Control procedures: 



The CA's policies and procedures sinould specify tine bacl<ground clnecl<s and clearance procedures 
required for trusted roles and non-trusted roles. As a minimum, verification checks on permanent staff 
should be performed at the time of job application and periodically for those individuals undertaking 
trusted roles. 



An individual's trusted status shall be approved prior to gaining access to systems/facilities or 
performing actions requiring trusted status. 



CA employees and trusted roles shall sign a confidentiality (non-disclosure) agreement as a condition of 
employment. 



7 



Contractors who perform trusted roles shall be subject to at least the same background check and 
personnel management procedures as employees. 



8 



Any contract arrangement between contractors and CAs should allow for the provision of temporary 
contract personnel which explicitly allows the organization to take measures against contract staff who 
violate the organization's security policies. Protective measures may include: 

a) bonding requirements on contract personnel; 

b) indemnification for damages due to contract personnel willful harmful actions; 

c) financial penalties. 



9 



A formal disciplinary process should exist and be followed for employees who have violated 
organizational security policies and procedures. 



10 



Appropriate and timely actions should be taken when employment is terminated so that controls 
(e.g. access controls) are not impaired. 



11 



Duress alarms should be provided for personnel who might be the target of coercion. 



12 



All employees of the organization and, where relevant, third party contractors should receive 
appropriate training in organizational policies and procedures. 



8.2.5 Physical and environmental security 



Control objectives: 



The CA shall maintain controls to provide reasonable assurance that: 

• physical access to CA facilities is limited to authorized individuals; 

• CA facilities are protected from environmental hazards; 

• loss, damage or compromise of assets and interruption to business activities are prevented; 

• compromise of information and information processing facilities is prevented. 



Control procedures: 




CA facility physical security 


1 


Physical protection should be achieved through the creation of restricted security perimeters 
(i.e., physical and logical barriers). The CA's certificate manufacturing facility shall be protected with its 
own unique physical perimeter. 


2 


The perimeter of the building or site containing the CA's certificate manufacturing facility shall have a 
minimal number of controlled access points. 


3 


A manned reception area or other means of controlling physical access should be in place to restrict 
access to the building or site housing CA operations to authorized personnel only. 
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Control procedures: 



4 



Physical barriers sinould be in place (e.g. solid walls that extend from real floor to real ceiling) to prevent 
unauthorized entry and environmental contamination to the CA's certificate manufacturing facility. 



5 



Physical barriers should be in place (e.g. Faraday cage) to prevent electromagnetic radiation emissions 
for all root CA operations (e.g. key generation and certification of CA certificates) and where certificate 
policies dictate. 



6 



Fire doors on security perimeters around CA operational facilities should be alarmed and conform to 
local fire regulations. 



7 



Intruder detection systems should be installed and regularly tested to cover all external doors of the 
building housing the CA operational facilities. 



8 



CA operational facilities should be physically locked and alarmed when unoccupied. 



9 



All personnel should be required to wear visible identification. Employees should be encouraged to 
challenge anyone not wearing visible identification. 



10 



Access to CA operational facilities should be controlled and restricted to authorized persons through the 
use of authentication controls. 



11 



All personnel entering and leaving CA operational facilities should be logged (i.e., an audit trail of al 
access is securely maintained). 



12 



Visitors to CA facilities should be supervised and their date and time of entry and departure recorded. 



13 



Third party support services personnel should be granted restricted access to secure CA operational 
facilities only when required and such access is authorized and accompanied. 



14 



Access rights to CA facilities should be regularly reviewed and updated. 



Equipment security 



15 



The CA should maintain an equipment inventory. 



16 



Equipment should be sited or protected in order to reduce the risks from environmental threats and 
hazards, and opportunities for unauthorized access. 



17 



Equipment should be protected from power failures and other electrical anomalies. 



1i 



Power and telecommunications cabling carrying data or supporting CA services should be protected 
from interception or damage. 



19 



Equipment should be maintained in accordance with the manufacturer's instructions and/or other 
documented procedures to ensure its continued availability and integrity. 



20 



All items of equipment containing storage media (fixed and removable disks) should be checked to 
ensure that they do not contain sensitive data prior to their disposal. Storage media containing sensitive 
data should be physically destroyed or securely overwritten prior to disposal or re-use. 



General controls 



21 



Sensitive or critical business information should be locked away when not required and when the CA 
facility is vacated. 



22 



Procedures should require that personal computers and workstations be logged off or protected by key 
locks, passwords or other controls when not in use. 



23 



Procedures shall require that equipment, information and software belonging to the organization cannot 
be taken off-site without authorization. 
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8.2.6 Operations management 



Control objectives: 



The CA shall maintain controls to provide reasonable assurance that: 

• the correct and secure operation of CA information processing facilities is ensured; 

• the risk of CA systems failure is minimized; 

• the integrity of CA systems and information is protected against viruses and malicious software; 

• damage from security incidents and malfunctions is minimized through the use of incident reporting 
and response procedures; 

• media are securely handled to protect them from damage, theft and unauthorized access. 



Control procedures: 




Operational procedures and responsibilities 


1 


CA operating procedures should be documented and maintained for each functional area. 


2 


Formal management responsibilities and procedures should exist to control all changes to CA 
equipment, software and operating procedures. 


3 


Duties and areas of responsibility should be segregated in order to reduce opportunities for 
unauthorized modification or misuse of information or services. 


4 


Development and testing facilities should be separated from operational facilities. 




System planning and acceptance 


5 


Capacity demands should be monitored and projections of future capacity requirements made to ensure 
that adequate processing power and storage are available. 


6 


Acceptance criteria for new information systems, upgrades and new versions should be established and 
suitable tests of the system carried out prior to acceptance. 




Protection against viruses and malicious software 


7 


Detection and prevention controls to protect against viruses and malicious software should be 
implemented. Appropriate employee awareness programmes should be in place. 




Incident reporting and response 


8 


A formal security incident reporting procedure should exist setting out the actions to be taken on receipt 
of an incident report. This should include a definition and documentation of assigned responsibilities 
and escalation procedures. Any incidents should be reported to PA as a matter of urgency. 


9 


Users of CA systems with trusted roles should be required to note and report observed or suspected 
security weaknesses in, or threats to, systems or services to ensure an appropriate response to a 
security incident. 


10 


Procedures should exist and be followed for reporting hardware and software malfunctions. 


11 


Procedures should exist and be followed to ensure that faults are reported and corrective action is 
taken. 


12 


A formal problem management process should exist which allows the types, volumes and impacts of 
incidents and malfunctions to be documented, quantified and monitored. 
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Control procedures: 



Media handling and security 



13 



Procedures for the management of removable computer media should require the following: 

a) if no longer required, the previous contents of any re-usable media that are to be removed 
from the organization are erased or media is destroyed; 

b) authorization is required for all media removed from the organization and a record of all such 
removals to maintain an audit trail is kept; 

c) all media are stored in a safe, secure environment, in accordance with manufacturers' 
specifications. 



14 



Equipment containing storage media (i.e., fixed hard disks) should be checked to determine whether 
they contain any sensitive data prior to disposal or re-use. Storage devices containing sensitive 
information should be physically destroyed or securely overwritten prior to disposal or re-use. 



15 



Procedures for the handling and storage of information should exist and be followed in order to protect 
such information from unauthorized disclosure or misuse. 



1( 



System documentation should be protected from unauthorized access. 



8.2.7 System access management 



Control objectives: 



The CA shall maintain controls to provide reasonable assurance that CA system access is limited to 
authorized individuals. Such controls shall provide reasonable assurance that: 

• operating system access is limited to authorized individuals with predetermined task privileges; 

• access to network segments housing CA systems is limited to authorized individuals, applications 
and services; 

• CA application use is limited to authorized individuals. 



Control procedures: 



User access management 



Business requirements for access control should be defined and documented in an access control 
policy which includes at least the following: 

a) roles and corresponding access permissions; 

b) identification and authentication process for each user; 

c) segregation of duties; 

d) number of persons required to perform specific CA operations (i.e., m of n rule where m 
represents the number of key share holders required to perform an operation and « represents 
the total number of key shares). 



There should be a formal trusted role user registration and de-registration procedure for granting 
access to CA information systems and services. 



3 



The allocation and use of privileges should be restricted and dual controlled. 



4 



The allocation of passwords should be controlled through a formal management process. 



5 



Access rights for users with trusted roles should be reviewed at regular intervals. 
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Control procedures: 



Network access control 



6 



CA employed personnel should be provided with direct access only to the services that they have been 
specifically authorized to use. The path from the user terminal to computer services is controlled. 



7 



Remote access to CA systems, made by CA employees or external systems, if permitted should require 
mutual authentication. 



8 



Connections made by CA employees or CA systems to remote computer systems should be mutually 
authenticated. 



9 



Access to diagnostic ports should be securely controlled. 



10 



Controls (e.g. firewalls) should be in place to protect the CA's internal network domain from any 
unauthorized access from any other domain. 



11 



Controls should be in place to limit the network services (e.g. HTTP, FTP, etc.) available to authorized 
users in accordance with the CA's access control policies. The security attributes of all network services 
used by the CA organization should be documented by the CA. 



12 



Routing controls should be in place to ensure that computer connections and information flows do not 
breach the CA's access control policy. 



13 



The CA shall ensure that local network components (e.g. firewalls and routers) are kept in a physically 
secure environment and their configurations periodically audited for compliance with the CA's 
configuration requirements. 



14 



Sensitive data shall be encrypted when exchanged over public or untrusted networks. 



Operating system access control 



15 



Operating systems should be configured in accordance with the CA's operating system configuration 
standards and be periodically reviewed. 



16 



Operating system patches and updates should be applied in a timely manner when deemed necessary 
based on a risk assessment. 



17 



Automatic terminal identification should be used to authenticate connections to specific locations and to 
portable equipment. 



18 



Access to CA systems should require a protected log-on process. 



19 



All CA personnel users should have a unique identifier (user ID) for their personal and sole use so that 
activities can be traced to the responsible individual. Where shared or group accounts are required, 
other monitoring controls should be implemented to maintain individual accountability. 



20 



Uses of system utility programmes should be restricted to authorized personnel and be tightly 
controlled. 



21 



Inactive terminals serving CA systems should require re-authentication prior to use. 



22 



Restrictions on connection times should be used to provide additional security for high-risk applications. 



23 



Sensitive operating system data shall be protected against disclosure to unauthorized users. 



Application access control 



24 



Access to information and application system functions should be restricted in accordance with the CA's 
access control policy. 



25 



CA personnel shall be successfully identified and authenticated before using critical applications related 
to certificate management. 



26 
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8.2.8 Systems development and maintenance 



Control objective: 



The CA shall maintain controls to provide reasonable assurance that CA systems development and 
maintenance activities are authorized to maintain CA system integrity. 



Control procedures: 



1 



Business requirements for new systems, or enhancements to existing systems shall specify the control 
requirements. 



2 



Software testing and change control procedures should exist and be followed for the implementation of 
software on operational systems including scheduled software releases, modifications and emergency 
software fixes. 



Change control procedures should exist and be followed for the hardware, network component and 
system configuration changes. 



4 



Control should be maintained over access to program source libraries. 



5 



Systems should be reviewed and tested when operating system changes occur. 



6 



Modifications to software packages should be discouraged and all changes shall be strictly controlled. 



7 



The purchase, use and modification of software should be controlled and checked to protect against 
possible covert channels and Trojan code. This should include the authentication of the source of the 
software. These controls apply equally to outsourced software development. This should include 
accreditation to common criteria as defined by ISO 15408 or similar. 



8.2.9 Business continuity management 



Control objectives: 



The CA shall maintain controls to provide reasonable assurance of continuity of operations in the event of a 
disaster. Such controls shall include at a minimum: 

• the development and testing of a CA disaster recovery plan; 

• the storage of required cryptographic materials (i.e., secure cryptographic device and activation 
materials) at an alternate location; 

• the storage of back-ups of systems, data and configuration information at an alternate location; 

• the availability of an alternate site, equipment and connectivity to enable recovery. 

The CA shall maintain controls to provide reasonable assurance that potential disruptions to subscribers and 
relying parties are minimized as a result of the cessation or degradation of the CA's services. 
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Control procedures: 


1 


The CA should have a managed process for developing and maintaining its business continuity plans. 
The CA should have a business continuity planning strategy based on an appropriate risk assessment. 


2 


The CA should have a business continuity plan to maintain or restore the CA's operations in a timely 
manner following interruption to, or failure of, critical CA processes. The CA's business continuity plan 
should address the following: 

a) the conditions for activating the plans; 

b) emergency procedures; 

c) fallback procedures; 

d) resumption procedures; 

e) a maintenance schedule for the plan; 

f) awareness and education requirements; 

g) the responsibilities of the individuals; 
h) recovery time objective (RTO); 

i) regular testing of contingency plans. 


3 


The CA's business continuity plans should include disaster recovery processes for all critical 
components of a CA system, including the hardware, software and keys, in the event of a failure of one 
or more of these components. Specifically: 

a) cryptographic devices used for storage of back-up CA private keys should be securely stored 
at an off-site location in order to be recovered by the CA in the event of a disaster at the 
primary CA facility; 

b) the requisite secret key shares or key components, needed to use and manage the disaster 
recovery cryptographic devices, should also be securely stored at an off-site location. 


4 


Back-up copies of essential business information should be regularly taken. The security requirements 
of these copies should be consistent with the controls for the information backed up. 


5 


The CA should identify and arrange for an alternate site where core PKI operations can be restored in 
the event of a disaster at the CA's primary site. Fallback equipment and back-up media should be sited 
at a safe distance to avoid damage from disaster at the main site. 


6 


The CA's business continuity plans should include procedures for securing its facility to the extent 
possible during the period of time following a disaster and prior to restoring a secure environment either 
at the original or a remote site. 


7 


The CA's business continuity plans should address the recovery procedures used if computing 
resources, software, and/or data are corrupted or suspected to be corrupted. 


8 


Business continuity plans should be tested regularly to ensure that they are up-to-date and effective. 


9 


Business continuity plans should be maintained by regular reviews and updates to ensure their 
continuing effectiveness. 



8.2.10 Monitoring and compliance 



Control objectives: 



The CA shall maintain controls to provide reasonable assurance that: 

• it conforms with the relevant legal, regulatory and contractual requirements; 

• compliance with the CA's security policies and procedures is ensured; 

• unauthorized CA system usage is detected. 
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Control procedures: 




Compliance with legal requirements 


1 


The CA should have procedures to ensure that all relevant statutory, regulatory and contractual 
requirements are explicitly defined and documented for each information system. 


2 


The CA should have implemented procedures to ensure compliance with legal restrictions on the use of 
material with respect to intellectual property rights, and on the use of proprietary software products. 


3 


Controls should be in place to ensure compliance with national agreements, laws, regulations or other 
instruments to control the access to or use of cryptographic hardware and software. 


4 


Procedures should exist to ensure that personal information is protected in accordance with relevant 
legislation. 


5 


The information security policy should address the following: 

a) the information that must be kept confidential by CA or RA; 

b) the information that is not considered confidential; 

c) the policy on release of information to law enforcement officials; 

d) information that can be revealed as part of civil discovery; 

e) the conditions upon which information may be disclosed with the subject's consent; 

f) any other circumstances under which confidential information may be disclosed. 


6 


Important records of the CA should be protected from loss, destruction and falsification. 




Review of security policy and technical compliance 


7 


Managers should be responsible for ensuring that security procedures within their area of responsibility 
are carried out correctly. 


8 


The CA's operations should be subject to regular review to ensure compliance with its CPS. 


9 


CA systems should be periodically checked for compliance with security implementation standards. 




Monitoring system access and use 


10 


Procedures for monitoring the use of CA systems should be established and the results of the 
monitoring activities reviewed regularly. Alerting mechanisms should be implemented to detect 
unauthorized access. 



8.2.11 Audit logging 



Control objectives: 



The CA shall maintain controls to provide reasonable assurance that: 

• CA environmental, key management and certificate management events are accurately and 
appropriately logged; 

• the confidentiality and integrity of current and archived audit logs are maintained; 

• audit logs are completely and confidentially archived in accordance with disclosed business 
practices; 

• audit logs are reviewed periodically by authorized personnel. 
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Control procedures: 




Audit logs 


1 


The CA shall generate automatic (electronic) and manual audit logs as required by law and the 
requirements of the certificate policy. 


2 


All journal entries shall include the following elements: 

a) date and time of the entry; 

b) serial or sequence number of entry (for automatic journal entries); 

c) kind of entry; 

d) source of entry (e.g. terminal, port, location, customer, etc.); 

e) identity of the entity making the journal entry. 




Events logged 


3 


The CA should log the following CA and subject (if applicable) key life cycle management related 
events: 

a) CA key generation; 

b) installation of manual cryptographic keys and its outcome (with the identity of the operator); 

c) CA key back-up; 

d) CA key storage; 

e) CA key recovery; 

f) CA key escrow activities (if applicable); 

g) CA key usage; 
h) CA key archival; 

1) withdrawal of keying material from service; 

j) CA key destruction; 

k) identity of the entity authorizing a key management operation; 

1) identity of the entities handling any keying material (such as key components or keys stored in 
portable devices or media); 

m) custody of keys and of devices or media holding keys; 

n) compromise of a private key. 


4 


The CA should log the following cryptographic device life cycle management related events: 

a) device receipt and installation; 

b) placing into or removing a device from storage; 

c) device activation and usage; 

d) device de-installation; 

e) designation of a device for service and repair; 

f) device retirement. 
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Control procedures: 


5 


If the CA provides subject key management services, tine CA sliouid iog tine following subject key life 




cycle management related events: 




a) key generation; 




b) key distribution (if applicable); 




c) key back-up (if applicable); 




d) key escrow (if applicable); 




e) key storage; 




f) key recovery (if applicable); 




g) key archival (if applicable); 




h) key destruction; 




i) identity of the entity authorizing a key management operation; 




j) key compromise. 


6 


The CA should record (or require that the RA record) the following certificate application information: 




a) the method of identification applied and information used to meet "know-your-customer" 




requirements; 




b) record of unique identification data, numbers or a combination thereof (e.g. applicant's driving 




license number) of identification documents, if applicable; 




c) storage location of copies of applications and identification documents; 




d) identity of entity accepting the application; 




e) method used to validate identification documents, if any; 




f) name of receiving CA or submitting RA, if applicable; 




g) the subject's acceptance of the subscriber agreement; 




h) where required under privacy legislation, the subscriber's consent to allow the CA to keep 




records containing personal data and pass this information to specified third parties, and 




publication of certificates. 


7 


The CA should log the following certificate life cycle management related events: 




a) receipt of requests for certificate(s) - including initial certificate requests, renewal requests and 




re-key requests; 




b) submissions of public keys for certification; 




c) change of affiliation of an entity; 




d) generation of certificates; 




e) distribution of the CA's public key; 




f) certificate revocation requests; 




g) certificate revocation; 




h) certificate suspension requests (if applicable); 




i) certificate suspension and re-activation; 




j) generation and issuance of certificate revocation lists. 
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Control procedures: 



The CA should log the following security-sensitive events: 

a) security sensitive files or records read or written including the audit log itself; 

b) actions taken against security sensitive data; 

c) security profile changes; 

d) use of identification and authentication mechanisms, both successful and unsuccessful 
(including multiple failed authentication attempts); 

e) security-sensitive non-financial transactions (e.g. account or name/address changes, etc.); 

f) system crashes, hardware failures and other anomalies; 

g) actions taken by individuals in trusted roles, computer operators, system administrators and 
system security officers; 

h) change of affiliation of an entity; 

i) decisions to bypass encryption/authentication processes or procedures; 

j) access to the CA system or any component thereof. 



9 



Audit logs should not record the private keys in any form (e.g. plaintext or enciphered). 



10 



CA computer system clocks should be synchronized for accurate recording as defined in the CP or CPS 
that specifies the accepted time source. 



Audit log protection 



11 



Current and archived audit logs should be maintained in a form that prevents their modification or 
unauthorized destruction. 



12 



Digital signatures should be used to protect the integrity of audit logs where applicable or required to 
satisfy legal requirements. 



13 



The private key used for signing audit logs should not be used for any other purpose. This should apply 
equally to a symmetric secret key used with a symmetric MAC mechanism. 



Audit log archival 



14 



The CA should archive audit log data on a periodic basis. 



15 



In addition to possible regulatory stipulation, a risk assessment should be performed to determine the 
appropriate length of time for retention of archived audit logs. 



16 



The CA should maintain archived audit logs at a secure off-site location for a predetermined period as 
determined by risk assessment and legal requirements. 



Review of audit logs 



17 



Current and archived audit logs should only be retrieved by authorized individuals for valid business or 
security reasons. 



18 



Audit logs should be reviewed according to the practices established in the CPS. 



19 
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resources, sudden and unexpected increases in volume and access at unusual times or from unusual 
places. 
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8.3 CA key life cycle management controls 
8.3.1 CA key generation 



Control objective: 



The CA shall maintain controls to provide reasonable assurance that CA key pairs are generated in 
accordance with defined key generation ceremony scripts and the requirements of the CPS. 



Control procedures: 




Generation of CA keys including root CA keys 


1 


CA key generation shall be performed in accordance with a detailed CA key generation ceremony script 
that specifies the steps to be performed and participant responsibilities. The CA key generation script 
shall include the following: 

a) definition of roles and responsibilities; 

b) approval for conduct of the key generation ceremony; 

c) cryptographic hardware and activation materials required for the ceremony; 

d) specific steps performed during the key generation ceremony; 

e) procedures for secure storage of cryptographic hardware and activation materials following the 
key generation ceremony; 

f) sign-off from participants and witnesses indicating whether key generation ceremony was 
performed in accordance with the detailed key generation ceremony script; 

g) notation of any deviations from the key generation ceremony script. 
Refer to Annex D for additional discussion of CA key generation ceremonies. 


2 


Generation of CA keys shall occur within a cryptographic module meeting the requirements of 
ISO 15782-1 and the business requirements in accordance with the CPS. Such cryptographic devices 
should perform key generation using a random number generator (RNG) or pseudo random number 
generator (PRNG) as specified in ISO/IEC 18032. 


3 


Generation of CA keys shall be undertaken in a physically secured environment (see 8.2.5) by 
personnel in trusted roles (see 8.2.4) under the principles of multiple control and split knowledge. 
(See Annex D) 


4 


The CA should generate its own key pair in the same cryptographic device in which it will be used or the 
key pair is injected directly from the device where it was generated into the device where it will be used. 


5 


CA key generation should generate keys which: 

a) are appropriate for the intended application or purpose and commensurate with the identified 
risks; 

b) use an approved algorithm as specified in ISO/IEC 18033, parts 1 to 4; 

c) have a key length that is appropriate for the algorithm and for the validity period of the CA 
certificate; 

d) take into account requirements on parent and subordinate CA key sizes; 

e) are in accordance with the CP. 


6 


Generation of CA keys should result in key size in accordance with the CP. The public key length to be 
certified by a CA shall be less than or equal to that of the CA's private signing key. 


7 


The integrity of the hardware/software used for key generation and the interfaces to the 
hardware/software should be tested before production usage. 
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8.3.2 CA key storage, back-up and recovery 



Control objectives: 



The CA shall maintain controls to provide reasonable assurance that: 

• CA private keys remain confidential and maintain their integrity; 

• access to CA cryptographic hardware is limited to authorized individuals. 



Control procedures: 


1 


The CA's private (signing and confidentiality) keys should be stored and used within a secure 
cryptographic device meeting the appropriate ISO 15408 protection profile or FIPS 140-2 level 
requirement based on a risk assessment and the business requirements of the CA and in accordance 
with the CA's CPS and applicable certificate policy(ies). 


2 


If the CA's private keys are not exported from a secure cryptographic module, then the CA private key 
should be generated, stored and used within the same cryptographic module. 


3 


If the CA's private keys are exported from a secure cryptographic module to secure storage for 
purposes of offline processing or back-up and recovery, then they shall be exported within a secure key 
management scheme that may include any of the following: 

a) cipher-text using a key which is appropriately secured; 

b) encrypted key fragments using multiple control and split knowledge/ownership; 

c) another secure cryptographic module such as a key transportation device using multiple 
control. 


4 


If the CA's private keys are backed up, they should be backed up, stored and recovered by authorized 
personnel in trusted roles, using multiple controls in a physically secured environment. The number of 
personnel authorized to carry out this function shall be kept to a minimum. 


5 


If the CA's private keys are backed up, back-up copies of the CA private keys should be subject to the 
same or greater level of security controls as keys currently in use. The recovery of the CA's keys shall 
be carried out in as secure a manner as the back-up process. 




CA cryptographic device life cycle management 


6 


Policies and procedures should require that CA cryptographic hardware be sent from the manufacturer 
via registered mail (or equivalent) using tamper-evident packaging. Upon the receipt of CA 
cryptographic hardware from the manufacturer, authorized CA personnel should inspect the tamper- 
evident packaging to determine whether the seal is intact. 


7 


Upon the receipt of CA cryptographic hardware from the manufacturer, acceptance testing and 
verification of firmware settings should be performed. Upon the receipt of CA cryptographic hardware 
that has been serviced or repaired, acceptance testing and verification of firmware settings should be 
performed. 


8 


To prevent tampering, CA cryptographic hardware should be stored and used in a secure site, with 
access limited to authorized personnel, having the following characteristics: 

a) inventory control processes and procedures to manage the origination, arrival, condition, 
departure and destination of each device; 

b) access control processes and procedures to limit physical access to authorized personnel; 

c) recording of all successful or failed access attempts to the CA facility and device storage 
mechanism (e.g. a safe) in audit logs; 

d) incident handling processes and procedures to handle abnormal events, security breaches, 
and investigation and reports; 

e) audit processes and procedures to verify the effectiveness of the controls. 
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Control procedures: 



9 



When not attached to the CA system, the CA cryptographic hardware should be stored in a tamper- 
resistant container that is stored securely under multiple controls (i.e., a safe). 



10 



The handling of CA cryptographic hardware, including the following tasks, should be performed in the 
presence of no less than two trusted employees: 

a) installation of CA cryptographic hardware; 

b) removal of CA cryptographic hardware from production; 

c) servicing or repair of CA cryptographic hardware (including installation of new hardware, 
firmware or software); 

d) disassembly and permanent removal from use. 



11 



Devices used for private key storage and recovery and the interfaces to these devices should be tested 
before usage for integrity (e.g. following manufacturer's instructions). 



8.3.3 CA public key distribution 



Control objective: 



The CA shall maintain controls to provide reasonable assurance that the integrity and authenticity of the CA 
public key and any associated parameters are maintained during initial and subsequent distribution. 



Control procedures: 


1 


The CA should provide a mechanism for validating the authenticity and integrity of the CA's public keys. 
For the root CA the distribution process (e.g. using a self-signed certificate), an out-of-band notification 
mechanism shall be used. Where a self-signed certificate is used for any CA, then CA shall provide a 
mechanism to verify the authenticity of the self-signed certificate (e.g. publication of the certificate's 
fingerprint). 

For subsequent and/or subordinate CA public keys, these shall be validated, by using a chaining 
method or similar process, to link back to trusted root certificate. For a new root certificate, an out-of- 
band process may be required. 


2 


The initial distribution mechanism for the CA's public key should be controlled as documented in the 
CA's CPS. CA public keys should be initially distributed within a certificate using one of the following 
methods in accordance with the CA's CPS: 

a) machine readable media (e.g. smart card, CD ROM) from an authenticated source; 

b) embedding in an entity's cryptographic module; 

c) other secure means that ensure authenticity and integrity. 


3 


The CA's public key should be changed (re-keyed) periodically according to the requirements of the 
CPS. Sufficient advance notice should be provided to avoid disruption of the CA services. 


4 


The subsequent distribution mechanism for the CA's public key should be controlled as documented in 
the CA's CPS. 


5 


If an entity already has an authenticated copy of the CA's public key, a new CA public key should be 
distributed using one of the following methods in accordance with the CA's CPS: 

a) direct electronic transmission from the CA; 

b) placing in a remote cache or directory; 

c) loading into a cryptographic module; 

d) any of the methods used for initial distribution. 
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8.3.4 CA key usage 



Control objective: 



The CA shall maintain controls to provide reasonable assurance that CA keys are used only for their 
intended functions in their predetermined locations. 



Control procedures: 



The activation of the CA private signing key should be performed using multi-party control (i.e., m of «) 
with a minimum value of three recommended for m. 



1 



2 



If necessary, based on a risk assessment, the activation of the CA private key should be performed 
using multifactor authentication (e.g. smart card and password, biometric and password, etc.). 



3 



CA signing key(s) used for generating certificates and/or issuing revocation status information, shall not 
be used for any other purpose. 



4 



The CAs private keys shall only be used within physically secure premises. (Refer to 8.2.5) 



5 



The CA should cease to use a key pair at the end of the key pair's defined operational lifetime or when 
the compromise of the private key is known or suspected. 



Correct processing of CA cryptographic hardware should be verified on a periodic basis. 



An annual review should be required by the PA on key lengths to determine the appropriate key usage 
period and the recommendations shall be acted upon. 



8.3.5 CA key archival and destruction 



Control objectives: 



The CA shall maintain controls to provide reasonable assurance that: 

• archived CA keys remain confidential and secured in the event that they are put back into 
production; 

• CA keys are completely destroyed at the end of the key pair life cycle as determined by the CPS. 



Control procedures: 




CA key archival 


1 


Archived CA keys should be subject to the same or greater level of security controls as keys currently in 
use. 


2 


The CAs private keys shall not be destroyed until the business purpose or application has ceased to 
have value or legal obligations have expired. 


3 


Archived keys should only be put back into production when a security incident results in a loss of 
production keys or where historical evidence requires validation. Control process should be required to 
ensure the integrity of the CA systems and the key sets. 


4 


Archived keys should be recovered for the shortest possible time period to meet business requirements. 




CA key destruction 


5 


Authorization to destroy a CA private key and how the CA's private key is destroyed (e.g. token 
surrender, token destruction or key overwrite) should be limited in accordance with the CA's CPS. 


6 


All copies and fragments of the CA's private key should be destroyed in a manner such that the private 
key cannot be retrieved. 


7 


If a CA cryptographic device is being permanently removed from service, then any key contained within 
the device that has been used for any cryptographic purpose should be erased from the device. 
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8.3.6 CA key compromise 



Control objective: 



The CA shall maintain controls to provide reasonable assurance that continuity of operations is maintained in 
the event of the compromise of the CA's private keys. 



Control procedures: 


1 


The CA's business continuity plans should address the compromise or suspected compromise of a 
CA's private keys as a disaster. 


2 


In the event of the compromise or suspected compromise of a CA's private signing key, disaster 
recovery procedures including the revocation and re-issuance of all certificates that were signed with 
that CA's private key shall exist. 


3 


The recovery procedures used if the CA's private key is compromised should include the following 
actions: 

a) how to secure key usage in the environment is re-established; 

b) how the CA's old public key is revoked; 

c) the notification procedures for affected parties (e.g. impacted CAs, repositories, subscribers 
and CVSPs); 

d) how the CA's new public key is provided to the end entities and relying parties together with 
the mechanism for their authentication; 

e) how the subject's public keys are recertified. 


4 


In the event that the CA has to replace its root CA private key, procedures should be in place for the 
secure and authenticated revocation of the following: 

a) the old CA root public key; 

b) the set of all certificates (including any self-signed) issued by a root CA or any CA based on 
the compromised private key; 

c) any subordinate CA public keys and corresponding certificates that require recertification. 


5 


The CA's business continuity plan for key compromise should address who is notified and what actions 
are taken with system software and hardware, symmetric and asymmetric keys, previously generated 
signatures and encrypted data. 


6 


The CA business continuity plan should consider key replication techniques such as those described in 
Annex J of ISO 1 5782-1 :2003. 



8.4 Subject key life cycle management controls 

8.4.1 CA-provided subject key generation services (if supported) 



Control objectives: 



If the CA provides subscriber key management services, the CA shall maintain controls to provide 
reasonable assurance that: 

• subject keys generated by the CA (or RA or card bureau) are generated in accordance with the CP; 

• subject keys generated by the CA (or RA or card bureau) are securely distributed to the subject by 
the CA (or RA or card bureau). 
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Control procedures: 




CA (or RA or card bureau) provided subject key generation 


1 


Subject l<ey generation performed by tine CA (or RA or card bureau) sinould occur witinin a secure 
cryptographic device, meeting tine appropriate ISO 15782-1 level requirement based on a risk 
assessment and the business requirements of the CA and in accordance with the applicable CP. Such 
cryptographic devices shall perform subject key generation using a random number generator (RNG) or 
pseudo random number generator (PRNG) as specified in ISO/IEC 18032. 


2 


Subject key generation performed by the CA (or RA or card bureau) should use a key generation 
algorithm as specified in the CP. 


3 


Subject key generation performed by the CA (or RA or card bureau) should result in key sizes in 
accordance with the CP. 


4 


Subject key generation performed by the CA (or RA) should be performed by authorized personnel in 
accordance with the CA's CPS. 


5 


When subject key generation is performed by the CA (or RA or card bureau), the CA (or RA or card 
bureau) should securely (confidentially) deliver the subject key pair(s) generated by the CA (or RA or 
card bureau) to the subject in accordance with the CP. 



8.4.2 CA-provided subject key storage and recovery services (if supported) 



Control objectives: 



If the CA provides subject confidentiality key storage, recovery or escrow services, the CA shall maintain 
controls to provide reasonable assurance that: 

• subject private keys stored by the CA remain confidential and maintain their integrity; 

• subject private keys archived by the CA remain confidential; 

• subject private keys stored by the CA are completely destroyed at the end of the key pair life cycle; 

• subject private keys escrowed by the CA remain confidential. 



Control procedures: 




CA-provided subject key storage, back-up and recovery 


1 


Subject private keys stored by the CA (or RA) should be stored in encrypted form using a cryptographic 
algorithm and key length based on a risk assessment and requirements of the CP. 


2 


If the CA generates key pair(s) on behalf of a subscriber, the CA (or RA) should ensure that subject's 
private keys are not disclosed to any entity other than the owner (i.e., the subject) of the keys. 


3 


If the CA (or RA) generates public/private signing key pair(s), it shall not maintain a copy of any private 
signing key, once the subject confirms receipt of that key. 


4 


If the CA (or RA) provides subject (confidentiality) key storage, back-up and recovery, subject private 
(confidentiality) key back-up and recovery then these services shall only be performed by authorized 
personnel. 


5 


If the CA (or RA) provides subject key storage, back-up and recovery, controls should exist to ensure 
that the integrity of the subject's private (confidentiality) key is maintained throughout its life cycle. 
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Control procedures: 




CA-provided subject key archival 


6 


Subject private (confidentiality) keys archived by the CA should be stored in encrypted form using a 
cryptographic algorithm and key length based on a risk assessment and the requirements of the CP. 


7 


If the CA provides subject (confidentiality) key archival, all archived subscriber keys should be 
destroyed at the end of the archive period. 




CA-provided subject key destruction 


8 


If the CA provides subject (confidentiality) key storage, authorization to destroy a subject's private key 
and the means to destroy the subject's private (confidentiality) key (e.g. key overwrite) should be limited 
in accordance with the CP. 


9 


If the CA provides subject (confidentiality) key storage, all copies and fragments of the subject's private 
key should be destroyed at the end of the key pair life cycle. 




CA-provided subject key escrow 


10 


Subject private (confidentiality) keys escrowed by the CA for purposes of access by law enforcement 
should be stored in encrypted form using a cryptographic algorithm and key length based on a risk 
assessment and the requirements of the CP. 



8.4.3 Integrated circuit card (ICC) life cycle management (if supported) 



Control objectives: 



If the CA (or RA) distributes subject key pairs and certificates using integrated circuit cards (iCCs), the CA 
(or RA) shall maintain controls to provide reasonable assurance that: 

• ICC procurement, preparation and personalization are securely controlled by the CA (or RA or card 
bureau); 

• ICC usage is enabled by the CA (or RA or card bureau) prior to ICC issuance; 

• ICCs are securely stored and distributed by the CA (or RA or card bureau); 

• ICCs are securely replaced by the CA (or RA or card bureau); 

• ICCs returned to the CA (or RA or card bureau) are securely terminated. 



Control procedures: 



ICC procurement 



If the CA or RA engages a card bureau then a formal contract shall exist between the relevant parties. 
While card issuing functions may be delegated to third parties, the CA shall retain responsibility and 
liability for the ICCs. 



2 



ICCs should be logically protected during transport between the card manufacturer and the card issuer 
through the use of a secret transport key or pass phrase. 



3 



ICCs issued to subject should meet the appropriate ISO/IEC 15408 protection profile, ISO card 
standard [e.g. ISO/IEC 7810, ISO/IEC 7811 (parts 1-5), ISO/IEC 7813, ISO/IEC 7816 (parts 1-12 
and 15), ISO 10202] or FIPS 140-2[''2] level requirement based on a risk assessment and the 
requirements of the CP. 



4 



The card bureau should verify the physical integrity of ICCs upon receipt from the card manufacturer. 



5 



ICCs should be securely stored and under inventory control while under the control of the card issuer. 
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Control procedures: 



Card preparation and personalization 

ICC preparation processes and procedures, including the following, should exist and be followed: 

a) loading of the card operating system; 

b) creation of logical data structures (card file system and card security domains); 

c) loading of applications; 

d) logically protecting the ICC to prevent unauthorized modification of the card operating system, 
card file system, card security domains and applications. 



ICC personalization processes and procedures, including the following, should exist and be followed: 

a) the loading of identifying information on to the card; 

b) generation of subject key pair(s) in accordance with 8.4.1 and the CP; 

c) loading subject private key(s) on to the ICC (if generated outside the card) in encrypted form; 

d) loading subject certificate(s) on to the ICC; 

e) loading the CA and other certificates for the contractual environment on to the ICC; 

f) logically protecting the ICC from unauthorized access. 



8 



The card bureau or CA (or RA) should log ICC preparation and personalization in an audit log. 



9 



An ICC should not be issued unless the card has been prepared and personalized by the card bureau, 
the CA or the RA. 



10 



An ICC should be unusable unless in an activated state. 



ICC distribution 



11 



Processes and procedures should exist and be followed for the distribution, tracking and accounting for 
the safe receipt subscriber ICCs to subjects. 



12 



ICC initial activation data (initializing PIN) should be securely communicated to the subject or where 
applicable the subscriber using an out-of-band method. The subject shall be encouraged to change the 
initial activation data upon receipt to make the card active. 



13 



ICC distribution should be logged by the card bureau CA (or RA) in an audit log. 



Subject ICC usage 



14 



The subject shall be provided with a mechanism that protects the access to the card data including the 
private keys stored on the ICC during use by the subscriber (i.e., PIN access control mechanism - 
cardholder verification method). 



15 



The subject private keys on the ICC shall not be exported to an application to undertake cryptographic 
(i.e., signing) functions. 



1( 



The subject shall be required to use a mutual authentication mechanism for cryptographic application 
and card functions to ensure system integrity. 



17 



The subject shall be required to use an application that displays the message or the message's digest 
to the subject prior to signing message (or transaction) data. The subject ICC application shall produce 
audit logs of all uses of the ICC. This also includes all attempts in the private key owner verification 
process. 

NOTE This evidence may be presented by the subject or where applicable the subscriber, should relying 

parties dispute the authenticity and/or integrity of a transaction. 



18 
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Control procedures: 



ICC replacement 



19 



Processes and procedures should exist and be followed for replacement of a subject's lost or damaged 
ICC. 



20 



In the event of card loss or damage, subject certificates should be renewed or re-keyed in accordance 
with the CP (see 8.5.2 and 8.5.3). 



21 



ICC replacement should be logged by the card bureau or CA (or RA) in an audit log. 



ICC termination 



22 



All ICCs returned to the ICC or CA (or RA) should be deactivated or securely destroyed to prevent 
unauthorized use. 



23 



ICC termination should be logged by the card bureau or CA (or RA) in an audit log. 



8.4.4 Requirements for subject key management 



Control objective: 


The CA shall prescribe the means to securely manage subject keys throughout the key life cycle. 




Control procedures: 




Subject key generation 


1 


The CP shall specify the appropriate ISO 15782-1/FIPS 140-2 level requirement for cryptographic 
modules used for subject key generation. 


2 


The CP shall specify the key generation algorithm(s) that may be used for subject key generation. 


3 


The CP shall specify the acceptable key sizes for subject key generation. 




Subject key storage, back-up and recovery 


4 


The CA or RA shall provide or make available the mechanisms to allow the subscriber to access (i.e., 
private key owner verification method), manage and control the usage of their private keys. 


5 


The CP shall specify the private key protection requirements for stored subject private keys. 


6 


The CP shall state the circumstances and authority of when the subject's private key will be restored 
and the control processes. 


7 


The CP shall specify the private key protection requirements for back-up copies of subject private keys 
stored by the subject. 




Subject key usage 


8 


Banking terms and conditions (or separate subscriber agreements) shall describe the required 
processes to be followed by the subscriber (and where applicable the subjects) of any use of the 
cryptographic mechanism (e.g. HSM or ICC and software application). 


9 


The CP shall specify the acceptable uses for subject key pairs. 


10 


The CP shall specify the requirements for subject key usage. 




Subject key archival 


11 


The CP shall specify the private key protection requirements for archived subject private keys. 


12 


The CP shall specify the requirements for destruction of archived subject keys at the end of the archive 
period. 
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Control procedures: 



Subject key destruction 



13 



The CP shall specify the means through which subject key destruction may be performed. 



14 



The CP or CPS shall specify the requirements for destruction of all copies and fragments of the 
subject's private key at the end of the key pair life cycle. 



Subject cryptographic hardware life cycle management 



15 



If required, the CP shall specify the requirements for use and handling of cryptographic hardware and 
subject authentication processes (and subsequent actions) where the cryptographic hardware is in 
other physical locations (i.e., an HSM attached to a mainframe or remote server). 



Subject key compromise 



16 



The CP shall specify the requirements for notification of the CA or RA in the event of subject key 
compromise. 



8.5 Certificate life cycle management controls 
8.5.1 Subject registration 



Control objectives: 



The CA shall maintain controls to provide reasonable assurance that: 

• subjects (or where applicable the subscribers) are accurately identified in accordance with the 
applicable "know-your-customer" requirements; 

• subjects' (or where applicable the subscriber's) certificate requests are accurate, authorized and 
complete. 



Control procedures: 



Identification and authentication 



The CA shall verify or require that the RA verify the credentials presented by a subject as evidence of 
identity or authority to perform a specific role in accordance with the certificate policy and appropriate 
regulatory and legal requirements. 

a) For individual end entity certificates, the CA or RA shall verify (as determined by the CP) the 
identity of the person whose name is to be included in the subject distinguished name field of 
the certificate. An unauthenticated individual name shall not be included in the subject 
distinguished name. 

b) For organizational certificates (including role based, server, network resource, code signing 
etc.), the CA or RA shall verify (as determined by the CP) the legal existence of the 
organization's name to be included in the organization attribute in the subject distinguished 
name field of the certificate and the authority of the requesting party. An unauthenticated 
organization name shall not be included in a certificate. 

c) For organizational certificates containing a domain name of an organization, the CA or RA 
shall verify (as determined by the CP) the organization's ownership, control or right to use the 
domain name included in the common name attribute of the subject distinguished name field 
of the certificate and the authority of the requesting party An unauthenticated domain name 
shall not be included in a certificate. 
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Control procedures: 



The CA or RA should verify the accuracy of the information included in the requesting entity's certificate 
request in accordance with the CP. 



3 



The CA or RA should check the certificate request for errors or omissions in accordance with the CP. 



4 



For end entity certificates, the CA should use the RA's public l<ey contained in the requesting entity's 
certificate request to verify signature on the certificate request submission. 



5 



The CA should verify the uniqueness of the subject's distinguished name within the boundaries or 
community defined by the CP. 



6 



Encryption and access controls should be used to protect the confidentiality and integrity of registration 
data in transit and in storage. 



7 



At the point of registration (before certificate issuance) the RA or CA should inform the subject or, 
where applicable, the subscriber of the terms and conditions regarding use of the certificate. 



8 



Before certificate issuance, the CA should inform the subject or, where applicable, the subscriber, of the 
terms and conditions regarding use of the certificate. 



Certificate request 



9 



The CA should require that an entity requesting a certificate must prepare and submit the appropriate 
certificate request data (registration request) to an RA (or the CA) as specified in the CP. 



10 



The CA should require that the requesting entity submit its public key in a self-signed message to the 
CA for certification. The CA should require that the requesting entity digitally sign the registration 
request using the private key that relates to the public key contained in the registration request in 
order to: 

a) allow the detection of errors in the certificate application process; 

b) prove possession of the companion private key for the public key being registered. 



11 



The certificate request shall be treated as acceptance of the terms of conditions by the requesting entity 
to use that certificate as described in the subscriber agreement. 



12 



The CA shall validate the identity of the RA authorized to issue registration requests under a specific 
CP. 



13 



The CA should require that RAs submit the requesting entity's certificate request data to the CA in a 
message (certificate request) signed by the RA. The CA should verify the RA's signature on the 
certificate request. 



14 



The CA should require that the RA secure that part of the certificate application process for which it 
(the RA) assumes responsibility in accordance with the CA's CPS. 



15 



The CA should require that RAs record their actions in an audit log. 



If 



The CA should verify the authenticity of the submission by the RA in accordance with the CA's CPS. 



8.5.2 Certificate renewal (if supported) 



Control objective: 



If certificate renewal is supported under the CP, the CA shall maintain controls to provide reasonable 
assurance that certificate renewal requests are accurate, authorized and complete. 
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Control procedures: 



Certificate renewal request 



Tine certificate renewal request should include at least the subject's distinguished name, the serial 
number of the certificate (or other information that identifies the certificate), and the requested validity 
period. (The CA will only renew certificates that were issued by itself). 



The CA should require that the requesting entity digitally sign the certificate renewal request using the 
private key that relates to the public key contained in the requesting entity's existing public key 
certificate. 



The CA shall issue a new certificate using the subject's previously certified public key, only if its 
cryptographic security is still sufficient for the new certificate's intended lifetime and no indications exist 
that the subject's private key has been compromised. 



The CA or the RA should process the certificate renewal data to verify the identity of the requesting 
entity and identify the certificate to be renewed. 



5 



The CA or the RA should validate the signature on the certificate renewal request. 



6 



The CA should verify the existence and validity of the certificate to be renewed. No renewal shall be 
permitted unless the existing certificate status is live (i.e., not revoked or suspended). 



The CA or the RA should verify that the request, including the extension of the validity period, meets the 
requirements defined in the CP. 

NOTE ISO 15782-1:2003, 6.3.9 also requires that the start date be the same in the renewed certificate as it is 

in the original certificate. 



8 



If an RA is used, the CA should require that the RAs submit the certificate renewal data to the CA in a 
message (certificate renewal request) signed by the RA. 



9 



The RA should secure that part of the certificate renewal process for which it (the RA) assumes 
responsibility in accordance with the CP. 



10 



The CA should require that external RAs record their actions in an audit log. 



11 



The CA should verify the authenticity of the submission by the RA. 



12 



The CA should verify the RAs signature on the certificate renewal request. 



13 



The CA should check the certificate renewal request for errors or omissions. This function may be 
delegated explicitly to the RA. 



14 



The CA or RA should notify subjects or, where applicable, subscribers prior to the expiration of their 
certificate, of the need for renewal in accordance with the CP. 



15 



The CA should issue a signed notification indicating the certificate renewal has been successful. 



1( 



The CA shall make the new certificate available to the end entity in accordance with the CP. 



8.5.3 Certificate re-l(ey 



Control objective: 



The CA shall maintain controls to provide reasonable assurance that certificate re-key requests are accurate, 
authorized and complete. 



Control procedures: 



1 



The CA should require that the requesting entity digitally sign using the existing private key the 
certificate re-key request containing the new public key. 



The CA or the RA should verify that the certificate re-key request meets the requirements defined in the 
relevant CP. 
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Control procedures: 



3 



If an RA is used, the CA should require that RAs submit the entity's certificate re-key request to the CA 
in a message signed by the RA. 



4 



If an RA is used, the CA should require that the RA secure that part of the certificate re-key process for 
which it (the RA) assumes responsibility. 



5 



If an RA is used, the CA should require that external RAs record their actions in an audit log. 



If an RA is used, the CA should verify the RA's signature on the certificate re-key request. 



7 



The CA or the RA should check the certificate re-key request for errors or omissions. 



8 



The CA or RA should notify subscribers prior to the expiration of their certificate of the need for re-key. 



9 



Prior to the generation and issuance of new certificates, the CA or RA should verify the following: 

a) the signature on the certificate re-key data submission; 

b) the existence and validity supporting the re-key request; 

c) that the request meets the requirements defined in the CP. 



10 



Where a new certificate is required by the subscriber, following revocation, the entity shall be required 
to apply for a new certificate in accordance with the CP. 



11 



Where a new certificate is required by the subscriber following expiration of the entity's certificate, the 
certificate may be automatically generated or the entity should be required to request a new certificate 
in accordance with the CP. 



8.5.4 Certificate issuance 



Control objective: 



The CA shall maintain controls to provide reasonable assurance that certificates are generated and issued 
(manufactured) in accordance with the CP. 



Control procedures: 


1 


The CA should generate certificates using certificate request data and manufacture the certificate as 
defined by the appropriate certificate profile in accordance with ISO 9594-8 and ISO 15782-1 formatting 
rules. 


2 


Validity periods should be set in the CP and are formatted in accordance with ISO 9594-8 and 
ISO 15782-1. 


3 


Extension fields should be formatted in accordance with ISO 9594-8 and ISO 15782-1. 


4 


The CA should sign the end entity's public key and other relevant information with the CA's private 
signing key. 


5 


Certificates should be issued based on approved subject registration, certificate renewal or certificate 
re-key requests in accordance with 8.5.1 to 8.5.3. 


6 


The CA should issue a signed notification to the RA when a certificate is issued to a subject for whom 
the RA submitted a certificate request. 


7 


The CA should issue an out-of-band notification to the subject when a certificate is issued. Where this 
notification includes initial activation data, then control processes shall ensure safe delivery to the 
subject. 


8 


Whether certificates expire, are revoked or are suspended, copies of certificates should be retained for 
the appropriate period of time specified in the CP. 
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8.5.5 Certificate distribution 



Control objective: 



The CA shall maintain controls to provide reasonable assurance that, upon issuance, complete and accurate 
certificates are available to any entity as defined in the CP. 



Control procedures: 


1 


The CA should make the certificates issued by the CA available to relevant parties using an established 
mechanism (e.g. a repository such as a directory) in accordance with the CP. Trusted mechanisms 
include: 

a) collection - repository or on-line directory service; 

b) delivery - distributed using protected media (e.g. CD-ROM or ICC). 


2 


Only authorized CA personnel should administer the CA's repository or alternative distribution 
mechanism. 


3 


The performance of the CA's repository or alternative distribution mechanism should be monitored and 
managed. 


4 


The integrity of the repository or alternative distribution mechanism should be maintained and 
administered. 


5 


Where required under privacy legislation, certificates should be made available for retrieval only in 
those cases for which the subject's consent is obtained. 



8.5.6 Certificate revocation 



Control objective: 



The CA shall maintain controls to provide reasonable assurance that certificates are revoked in a timely 
manner as dictated by risk, based on authorized and validated certificate revocation requests. 



Control procedures: 


1 


The CA shall provide a means of rapid communication to facilitate the secure and authenticated 
revocation of the following: 

a) one or more certificates of one or more subjects; 

b) the set of all certificates issued by a CA based on a single public/private key pair used by a CA 
to generate certificates; 

c) all certificates issued by a CA, regardless of the public/private key pair used. 


2 


The CA should verify or require that the RA verify the identity and authority of the entity requesting 
revocation of a certificate in accordance with the CP. 


3 


If an RA accepts revocation requests, the CA should require that the RA submit signed certificate 
revocation requests to the CA in an authenticated manner in accordance with the CP. 


4 


If an RA accepts and forwards revocation requests to the CA, the CA should provide a signed 
acknowledgement of the revocation request and confirmation of actions to the requesting RA. 


5 


The CA should update the certificate revocation list (CRL) and other certificate status mechanisms in 
the time frames specified within the CP and in accordance with the format defined in ISO 9594-8 and 
ISO 15782-1. 
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Control procedures: 



The CA should record all certificate revocation requests and their outcome in an audit log, as specified 
in Annex F of ISO 1 5782-1 :2003. 



7 



The CA or RA may provide an authenticated acknowledgement (signature or similar) of the revocation 
to the entity who perpetrated the revocation request. 



8 



Where certificate renewal is supported, when a certificate is revoked, all valid instances of the certificate 
should also be revoked and shall never be reinstated. 



9 



The subject (and where applicable, the subscriber) of a revoked or suspended certificate shall be 
informed of the change of status of its certificate. 



8.5.7 Certificate suspension (if supported) 



Control objective: 



If certificate suspension is supported, the CA shall maintain controls to provide reasonable assurance that 
certificates are suspended in a timely manner as dictated by risk, based on authorized and validated 
certificate suspension requests. 



Control procedures: 


1 


In accordance with the CA's CPS, the CA provides a means of rapid communication, in place to 
facilitate the secure and authenticated suspension of the following: 

a) one or more certificates of one or more subjects; 

b) the set of all certificates issued by a CA based on a single public/private key pair used by a CA 
to generate certificates; 

c) all certificates issued by a CA, regardless of the public/private key pair used. 


2 


The CA should verify or require that the RA verify the identity and authority of the entity requesting 
suspension and reactivation of a certificate in accordance with the CP. 


3 


If an RA accepts suspension requests, the RA should submit signed certificate suspension requests to 
the CA in an authenticated manner in accordance with the CP. 


4 


The CA or RA should notify the subject and, where applicable, the subscriber in the event of a 
certificate suspension. 


5 


Certificate suspension requests should be processed and validated in accordance with the 
requirements of the CP. 


6 


The CA should update the certificate revocation list (CRL) and other certificate status mechanisms upon 
certificate suspension. Changes in certificate status shall be completed in a time frame determined by 
the CP. 


7 


Certificates should be suspended only for the allowable length of time in accordance with the CP. 


8 


Once a certificate suspension (hold) has been issued, the suspension should be handled in one of the 
following three ways: 

a) an entry for the suspended certificate remains on the CRL with no further action; 

b) the CRL entry for the suspended certificate is replaced by a revocation entry for the same 
certificate; 

c) the suspended certificate is explicitly released and the entry removed from the CRL. 
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Control procedures: 



9 



A certificate suspension (Inold) entry sinould remain on tine CRL until tine expiration of tine underlying 
certificate or the expiration of the suspension, whichever is first. The CP may specify the maximum 
number of occasions when the certificate status may be suspended and the maximum periodicity for 
this status. If the limit is reached the PA may be notified for further investigation. 



10 



The CA should update the certificate revocation list (CRL) and other certificate status mechanisms upon 
the lifting of a certificate suspension in accordance with the CA's CP. 



11 



The CA should verify or require that the RA verify the identity and authority of the entity requesting that 
the suspension of a certificate be lifted. 



12 



Certificate suspensions and the lifting of certificate suspensions should be recorded in an audit log, as 
specified in Annex F of ISO 15782-1:2003. 



8.5.8 Certificate validation services 



Control objective: 



The CA shall maintain controls to provide reasonable assurance that timely, complete and accurate 
certificate status information (including certificate revocation lists and other certificate status mechanisms) is 
made available to relevant entities (subscribers and relying parties or their agents - i.e., CVSPs) in 
accordance with the CP. 



Control procedures: 


1 


The CA should make certificate status information available to relevant entities (relying parties or their 
agents) using an established mechanism in accordance with the CP. This may be achieved using: 

a) request response method - a request signed by the relying party to the certificate status 
provider's responder; in turn, the certificate status provider's responder responds with the 
certificate status duly signed (OCSP is an example protocol using this method); 

b) delivery method - a CRL signed by the CA and published within the policy's time frame. 




Applicable control procedures where CRLs are used 


2 


The CA shall digitally sign each CRL that it issues so that entities can validate the integrity of the CRL 
and the date and time of issuance. 


3 


The CA shall issue CRLs at regular intervals, as specified in the CP, even if no changes have occurred 
since the last issuance. 


4 


At a minimum, a CRL entry identifying a revoked certificate shall remain on the CRL until the end of the 
certificate's validity period. A retrospective view of a certificate status, at a given point in time, may be 
required. Therefore CRL entries may need to be held beyond the life of a certificate validity period to 
prove its validity at the time of use. 


5 


If certificate suspension is supported, a certificate suspension (hold) entry, with its original action date 
and expiration date should remain on the CRL until the normal expiration of the certificate or until the 
suspension is lifted. 


6 


CRLs should be archived in accordance with the requirements of the CP including the method of 
retrieval. 


7 


The CRL should contain entries for all revoked unexpired certificates issued by the CA. A retrospective 
view of a certificate status, at a given point in time, may be required. Therefore CRL entries may need 
to be held beyond the life of a certificate validity period to prove its validity at the time of use. 


8 


Old CRLs should be retained for the appropriate period of time specified in the CA's CP. 



66 



IS/ISO 21188: 2006 



Control procedures: 



Applicable control procedures where online certificate status mechanisms (e.g. OCSP) are used 



9 



If an online certificate status collection method (e.g., OCSP) is used, the CA should require that 
certificate status inquiries (e.g. OCSP requests) contain all required data in accordance with the CP. 



10 



Upon the receipt of a certificate status request (e.g. an OCSP request) from a relying party or its agent, 
the CA should return a definitive response to the relying party or its agent if: 

a) the request message is well formed; 

b) the certificate status provider responder is configured to provide the requested service; 

c) the request contains the information (i.e., certificate identity - serial number, OID, etc.) needed 
by the certificate status provider responder in accordance with the CP; 

d) the certificate status provider's responder is able to locate the certificate and interpret its 
status. 

Where these conditions are met, the CA or certificate status provider should produce a signed response 
message indicating the certificate's status in accordance with the CP. If any of the above conditions are 
not met then a status of "unknown" may be returned. 



11 



All response messages should be digitally signed and include all required data in accordance with 
the CP. 



8.6 CA certificate life cycle management controls 
8.6.1 Subordinate CA certificate life cycle management 



Control objectives: 



The parent CA shall maintain controls to provide reasonable assurance that: 

subordinate CA certificate requests are accurate, authenticated and approved; 

subordinate CA certificate replacement (renewal and re-key) requests are accurate, authorized and 
complete; 

new, renewed and re-keyed subordinate CA certificates are generated and issued in accordance 
with the CP; 

upon issuance, complete and accurate subordinate CA certificates are available to relevant entities 
(subscribers and relying parties) in accordance with the CP; 

subordinate CA certificates are revoked based on authorized and validated certificate revocation 
requests; 

timely, complete and accurate certificate status information (including CRLs and other certificate 
status mechanisms) is made available to any entity in accordance with the CP. 
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Control procedures: 




Subordinate CA (sub-CA) registration 


1 


Tine parent CP sinould specify tine requirements for submission of sub-CA certification requests. 


2 


Tine parent CA sinould autinenticate tine sub-CA certificate request in accordance witin tine parent's CP. 


3 


Tine parent CA sinould audit tine sub-CA certificate applicant's compliance with the requirements of the 
parent CA's CP before approving a sub-CA certificate request, or alternatively the sub-CA should 
present its CPS for audit. 




Sub-CA renewal 


4 


Where sub-CA certificate renewal is permitted, the parent CA's CP should specify the requirements for 
submission of sub-CA renewal requests. 


5 


Where sub-CA certificate renewal is permitted, the parent CA should authenticate the sub-CA certificate 
renewal request in accordance with the CA's CP. 




Sub-CA re-key 


6 


The parent CA's CP should specify the requirements for submission of sub-CA re-key requests. 


7 


The parent CA should authenticate the sub-CA certificate re-key request in accordance with the CP. 




Sub-CA certificate issuance 


8 


The parent CA should generate certificates: 

a) using the appropriate certificate profile in accordance with the CP and ISO 9594-8 and 
ISO 15782-1 formatting rules; 

b) with the validity periods formatted in accordance with ISO 9594-8, ISO 15782-1 and the CP; 

c) where extensions are used, with extension fields formatted in accordance with ISO 9594-8, 
ISO 15782-1 and the CP. 


9 


The parent CA should sign the sub-CA certificate with the parent CA's private signing key. 




Sub-CA certificate distribution 


10 


The parent CA should make sub-CA certificates available to relevant entities (e.g. relying parties) using 
an established mechanism (e.g. a repository such as a directory) in accordance with the Parent CA's 
CP. 




Sub-CA certificate revocation 


11 


The parent CA should verify the identity and authority of the entity requesting revocation of a sub-CA 
certificate in accordance with the parent CA's CP. 


12 


The parent CA should update the certificate revocation list (CRL) and other sub-CA certificate status 
mechanisms upon certificate revocation in accordance with the parent CA's CP. 




Sub-CA certificate status information processing 


13 


The parent CA should make sub-CA certificate status information available to relying parties using an 
established mechanism (e.g. CRL, OCSP, etc.) in accordance with the parent CA's CP. 
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Annex A 

(informative) 

Management by certificate policy 



A.1 Introduction and purpose of certificate policies 

This annex describes certificate poiicies and identifies Inow tiney may be implemented to effectively manage 
the risks of parties in a PKI with its focus on a contractual environment. This annex draws on RFC 36471'' ''1, its 
predecessor RFC 2527P1, ISO 15782-1 and ISO 15782-2 and provides further clarification on the use of 
certificate policies in a financial services environment. 

Certificate policies play a critical role in the administration of trusted transactions. The main purpose of a CP is 
to enable the relying party to determine whether the certificate and its underlying conditions are acceptable for 
a given transaction. Equally, the subscriber has clear guidance upon where they may use their private key to 
sign transactions and place reliance on the certification service to support it. 



A.2 Definition of a certificate policy 

A CP is a unique named set of rules which describes the applicability of a certificate within a specified 
community and/or class of application. A CP acts as a record of permitted usage and associated provisions in 
terms of respective obligations, including liability and governance, between all involved parties. A certificate 
policy is published under the responsibility of a policy authority. 

The CP should be used by various users of the certificate to decide whether or not to accept the binding 
between the subject (of the certificate) and the public key. The CP is represented by a registered object 
identifier (OID) in the X.509, version 3 certificate. 

The CP object identifier can be included in the following extensions in the X.509, version 3 certificates: 
certificate policies, policy mappings and policy constraints. The object identifier(s) may appear in none, some 
or all of these fields. The certificate policy may also be retrieved using a URL which may be identified in the 
certificate policies extension. 

The policy authority or its agents may provide signed paper copies of the certificate policy to potential 
subscribers as a form of contractual binding, or to relying parties, relying parties on the other hand may use 
electronic links to locate the certificate policy. A CVSP may supply a service to relying parties to validate 
certificates as well as the applicability of the associated certificate policy. 



A.3 Establishing policies in certificates 

OlDs are used to unambiguously identify certificate policies and policy qualifiers so that they can be 
processed by automated means in certificate-using applications and systems. These policies and policy 
qualifiers are listed in the certificate policies certificate extension by the issuing CA and are defined in 
ISO 15782-2 as: 

certificatePolicies EXTENSION : := { 

SYNTAX CertificatePoliciesSyntax 

IDENTIFIED BY id-ce-certif icatePolicies 
} 
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In the certificatePolicies certificate extension, tine object identifier id-ce-certificatePolicies 
identifies a value of ASN.1 type CertificatePoliciesSyntax, which is defined as: 

CertificatePoliciesSyntax : := SEQUENCE SIZE (1.. MAX) OF Policylnformation 

Policylnforitiation : := SEQUENCE { 

policyldentifier CertPolicyld, 

policyQualifiers PolicyQualifiers OPTIONAL 
} 

CertPolicyld : := OBJECT IDENTIFIER 

PolicyQualifiers : := SEQUENCE SIZE (1.. MAX) OF PolicyQualif ierlnfo 

When a certificatePolicies certificate extension is present in a certificate, it must have at least one 
value of type Policylnformation. Each instance of type Policylnformation must contain a value of 
type CertPolicyld, an object identifier that identifies a CP. The policyQualifiers component of 
Policylnformation lists the policy qualifiers associated with a given CP. This component is optional and 
need not be included. 

The certificate policies listed in a certificatePolicies certificate extension are those that are recognized 
by the issuing CA as being applicable to that certificate. This policy information can be used by a relying party 
to determine the appropriate use of the key pair certified by the CA. A relying party may require a particular 
policy to be present in this extension before it accepts the certificate as valid for a particular use. Typically, a 
CP may be associated with a set of application programs which may be used by the owner of the certified key, 
only when the CP is present. 

A criticality indicator in each certificatePolicies certificate extension may be set to either critical or non- 
critical by the certificate issuer. If this extension is set to critical, the extension indicates that the certificate 
should only be used by a relying party for the purposes implied by its certificate policies. A particular CP may 
require the certificate-using system to process any qualifier values in a particular way, to further restrict or to 
expand the valid uses of a certificate. 

If the certificate policies extension is set to non-critical, use of this extension does not necessarily constrain 
certificate-using systems to use the certificate in accordance with the policies listed in the certificate. But a 
relying party or computer application may require that a specific policy be present in order to use the 
certificate. Policy qualifiers may, at the option of the relying party, be processed or ignored. 

When CP qualifiers are associated with a given CP, the optional policyQualifiers component of type 
Policylnformation is present and contains at least one CP qualifier, a value of type 
PolicyQualif ierlnfo defined as: 

PolicyQualif ierlnfo : := SEQUENCE { 

policyQualifierld CERT-POLICY-QUALIFIER. &id ( {SupportedPolicyQualif iers} ) , 

qualifier CERT-POLICY-QUALIFIER. SQualif ier ( 

{ SupportedPolicyQualif iers } { @policyQualif ierld} ) 
OPTIONAL 
} 

SupportedPolicyQualif iers CERT-POLICY-QUALIFIER : := { ... } 

Type PolicyQualifierlnfo is composed of two components, policyQualifierld and qualifier, 
which are specified in terms of the &id and sQualifier fields of the information object class cert- 
POLICY-QUALIFIER. This class is defined as: 
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CERT -POLICY-QUALIFIER ::= CLASS { 

&id OBJECT IDENTIFIER UNIQUE, 

SQualifier OPTIONAL 

} 

WITH SYNTAX { POLICY-QUALIFIER-ID Sid [QUALIFIER-TYPE SQualifier] } 

The policyQualif ierld component of PolicyQualif ierlnfo is defined in terms of tine &id field and 
must contain an object identifier value. The optional qualifier component is defined in terms of the 
SQualifier field and can contain the value of any ASN.1 type. 

A value of the Policylnformation type identifies and conveys qualifier information for one CP. The component 
policyldentifier contains an identifier of a CP and the component policyQualifiers contains policy qualifier 
values for that element. 

Policy qualifier types can be registered by any organization. The following policy qualifier types are defined in 
IETF RFC 2459I81, Certificate and CRL Profile: 

a) The certification practice statement pointer qualifier contains a pointer to a certification practice statement 
(CPS) published by the CA. The pointer is in the form of a uniform resource locator (URL). 

b) The user notice qualifier contains a text string that is to be displayed to a certificate user (including 
subscribers and relying parties) prior to the use of the certificate. The text string may be an IA5 String or a 
BMP String - a subset of the ISO/IEC 10646-1 multiple octet coded character set. A CA may invoke a 
procedure that requires that the certificate user acknowledges that the applicable terms and conditions 
have been disclosed or accepted. 



A.4 Certificate applicability under a named certificate policy 

Once parties are able to identify and locate the CP relating to a certificate, the user must be able to determine 
what a certificate can be used for and any constraints. Policy authorities have the option of asking CAs to 
issue either: 

a) one certificate with restricted association to one specific CP; 
or 

b) allowing one certificate to be associated with many CPs. 

There are several issues here that require discussion. This is considered against the background of the 
following basic assumptions: 

— Certificate policies are customer oriented in that certificates provide a control mechanism to help manage 
risks related to services provided to customers. 

— Certificate policies and the applicability of a certificate need to be recognized by all parties including the 
issuer, the subscriber, the relying party and possibly the relying party's validation service provider. 

— In the emerging trust services marketplace, it appears that there will be a proliferation of certificates by 
various trust service providers. The variety of naming conventions in combination with the proliferation of 
certificates may create confusion for an 'uneducated' consumer base as to which certificate to use for a 
particular application. 

While customer knowledge on the management of certificates requires enhancing, and it may be argued that 
certificates should be transparent to some users, financial institutions may consider one-to-one as a prudent 
strategy initially. This will minimize confusion and facilitate learning on the part of the end user over a longer 
period to allow for familiarization and to allow time for software applications to handle multiple certificates 
more effectively. 
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One certificate witin one CP wiii aiso minimize tine level of consumer education for "how and why" a certificate 
may be used for particular applications. It is also essential that certificate policies are written in such a way 
that they are "customer friendly," unambiguous and clear in terms of responsibilities and liabilities. These are 
the terms and conditions for the subscriber's use of the certificate and must be clearly understood by them. 
Additionally, the relying party or their trust services provider will have definitive information as to which CP 
applies to the certificate presented. Unless this is stated explicitly in the transaction or predetermined, there 
must be a reliable mechanism to determine which is the applicable CP. 

Additionally, for cross-certification it will be essential to have clarity regarding which CP applies to extend the 
use of a certificate. The one CP for one certificate strategy will minimize the technical, organizational and 
operational requirements of cross-certification. 



A.5 Cross-certification, certificate chains, policy mapping and certificate policies 

A.5.1 Cross-certification 

Cross-certification is the reciprocal certification process of certificate policies issued by two or more different 
policy authorities. Cross-certification enables the reciprocal use of the certificates owned by different policy 
authorities. 

Cross-certification increases the usage and acceptability range of the subscriber's certificate under a given CP. 
Cross-certification requires a degree of conformity or equivalence in terms of interoperability of policy between 
the policy authorities and the controls implemented by the issuing CAs. 

A.5.2 Certificate chains 

When validating the acceptability of a certificate it may be necessary to not only validate the entire sequence 
of certificates from the end entity using the certificate up to the root certificate but also their respective 
certificates policies. 

An acceptable policy identifier is the identifier of the CP required by the user of the certification path or the 
identifier of a policy that has been declared equivalent to it through policy mapping (see A.5. 3). 

Setting the certificate policies extension field as critical, forces the application to check that acceptable 
certificate policies in the chain are present. It is therefore recommended that the certificate policies extension 
be implemented as a critical extension. This field is processed in concert with the policyConstraints extension 
(A.5.4) during the certification path validation as described in ITU-T Recommendation X.509. 

A.5. 3 Certificate policy mapping 

This extension allows the policy authority, through its certificate issuers, to indicate that one or more of its 
certificate policies is considered equivalent to another CP used in that domain. The assignment of CP 
mappings is restricted to the policy authority and certification authority, and may be further inhibited through 
the policyConstraints extension. This extension will support cross-certification by specifying the OlDs of 
equivalent certificate policies. 

The syntax of this extension is: 

policyMappings EXTENSION ::={ 

SYNTAX PolicyMappingsSyntax 

IDENTIFIED BY Id-ce-policyMappings } 

PolicyMappingsSyntax ::= SEQUENCE SIZE (1..MAX) OF SEQUENCE { 
issuerDomainPolicy CertPolicyld, 
subjectDomainPolicy CertPolicyld } 
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According to ISO 15782-2 this extension may, at tine discretion of tine certificate issuer and as stated in the CP, 
be either critical or non-critical. 

CAs should generate this extension for CA digital signature certificates where policy mapping is applicable 
and include a combination of issuerDomainPolicy field(s) and subjectDomainPolicy field(s) with the applicable 
CertPolicyld field(s). 

Relying parties should interpret the combination(s) of IssuerDomainPolicy and subjectDomainPolicy CP object 
identifiers as equivalent. 

A.5.4 Policy constraints 

The policy constraints extension supports two optional features. The first is the ability for a certification 
authority to require that explicit CP indications be present in all subsequent certificates in a certification path. 
Certificates at the start of a certification path may be considered by a certificate user to be part of a trusted 
domain (i.e., certification authorities are trusted for all purposes so no particular CP is needed in the certificate 
policies extension). Such certificates need not contain explicit indications of CP. However, when a certification 
authority in the trusted domain certifies outside the domain, it can activate the requirement for explicit CP in 
subsequent certificates in the certification path. When used, the requireExplicitPolicy constraint requires that 
all certificates include an acceptable policy, not just those that follow the certificate that asserts the 
requirement. 

The other optional feature in the policy constraints field is the ability for a certification authority to disable 
policy mapping by subsequent certification authorities in a certification path. It may be prudent to disable 
policy mapping when certifying outside the domain. This can assist in controlling risks due to transitive trust 
(e.g. a domain A trusts domain B, domain B trusts domain C, but domain A does not want to be forced to trust 
domain C). 

The syntax of this extension is: 

policyConstraints EXTENSION ::= { 

SYNTAX PolicyConstraintsSyntax 

IDENTIFIED BY id-ce-policyConstraints } 

PolicyConstraintsSyntax ::= SEQUENCE { 

requireExplicitPolicy [0] SkipCerts OPTIONAL, 

inhibitPolicyMapping [1] SkipCerts OPTIONAL } 

SkipCerts ::= INTEGER (O..MAX) 

According to ISO 15782-2 this extension should be flagged critical. 



A.6 Types of certificate 

The type of certificate that may be required is complex with a wide variety of user needs requiring a range of 
different solutions. The policy authority may adopt a general-purpose strategy for a CP without usage 
restriction. Alternatively, a policy authority may construct certificate policies for specific purposes to restrict 
inappropriate usage or to limit liability. 

Consequently, the main types of end-entity certificate are: 

— application-specific (attribute-based) certificates; these certificates are issued to support specific 
applications, products and/or services where the requirements for authorization are explicit; 

— generic certificates; a single certificate based on the authenticity of specific information proves the identity 
of the holder of a public key, which identity constitutes the basis for authorization. 

NOTE A single certificate may be used to support multiple applications. The use of a single certificate will need to 

meet the requirements of the most highly classified application. 
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It is assumed that general-purpose certificates will predominate for subscribers because: 

— ID-only based certificates are likely to become a commodity in the medium- to long-term; 

— in the medium- to long-term, attribute-based or customized certificates may be a source of added value; 

— the uses for digital signatures and certificates both internally and externally have yet to be fully exploited 
or developed. 

The amount of assurance required directly correlates to the business risks for each entity in a transaction. The 
degree of assurance will more often than not vary according to the party's role and the appetite for risk. A "fit- 
for-purpose" approach is discussed in A. 7. The early state of a market for trust services in general, combined 
with the technological immaturity of the marketplace, suggest that initial efforts to define an all-encompassing 
system allowing for policy granularity is not a feasible option for the initial deployment. 

It is recommended that generic certificates be issued to subscribers utilized to establish a system of minimum 
requirements for all categories of services for the initial stages for a PKI deployment. This approach takes into 
consideration the subsequent supplemental requirements that may be drawn up by the market for further 
categories of certificate policies and related trust services. 

There are other types of certificate policies designated for specific purposes, such as server certificates and 
using certificates to create a PKI hierarchy. 

A.7 Certificate classes and naming 

The use of certificate classes may be to distinguish between the different level of assurance and for describing 
specific third party obligations for issuing, managing, suspending and revoking certificates. Each level or class 
of certificate provides specific functionality and security features. 

A critical issue for the relying party and to a degree the subscriber is ascertaining the level of assurance a 
particular certificate provides issued under a CP. 

The identified options for policy authorities include the following. 

— CP classifications based upon arbitrary values, such as bronze, silver, gold: it should be noted that this 
would make it difficult to provide any linear measure of the specific security service capability. Differences 
between classes may be multidimensional and may contain distinct attributes that are not precisely 
comparable to other classes. The use of certificate class names is perceived to have a "relative value" for 
their use and functionality. 

— CP classifications based on recognized standards for contractual environment: for the end user the use of 
these certificate classes project an "absolute value" on the type of security and liability issues associated 
with their usage. 

The following assumptions also require consideration by policy authorities: 

— digital certificates may represent familiar brand names in the electronic marketplace; 

— consumer and business confidence is a measure of the recognition of brand(s) attached to security 
products and services, including the level of functionality and applicability of a certificate; 

— other naming conventions could be used which have no implicit value (e.g. 1, 2, 3) and concentrate on 
establishing usage differences rather than relative merit, however it seems unlikely in the context of 
financial services that these would be deemed appropriate to engender trust; 

— the use of standards serves as a universally understood benchmark, however, care needs to be 
exercised on level of prescription to avoid placing any restriction on usage. 
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Certificate ciassifications based on absoiute vaiues sucin as iow, medium and Inigin may not project tine type of 
image tinat financial institutions require for tine development of electronically based trust services. 

To promote wider acceptability and possibly reduce the level of end-user confusion for certificate usage, the 
recommendation is for certificate policies to conform with standards that are recognized or specifications 
agreed upon by all the parties in the contractual environment. 



A.8 Certificate policy provisions 

A.8.1 General 

This clause briefly describes the terms of a CP. 

A.8.2 Interpretation 

The CP should outline in its preamble what the CP is for in terms of service provision, the preconditions for the 
community and the relating legally binding contractual conditions. This may also include any regulatory 
requirements that are applicable to the community and use of the certificates under the CP. 

This section should describe the intended community for the certificates and where appropriate their intended 
usage (e.g. whether the certificate may be used for remote authentication purposes, digital signing or data 
confidentiality). It may also state any requirements for membership of the community (e.g. certificates might 
be issued to private account holders only, relying parties must have signed a relying party agreement with an 
approved or licensed entity as approved by the policy authority, etc.). 

A.8.3 Obligations 

The main responsibilities for each entity are stated in terms of their respective roles - policy authority, CA, 
subscriber, relying party and certificate validation service provider. 

The policy authority is responsible for ensuring it conducts an efficient and trustworthy service in line with 
terms agreed with contracting parties or schemes. The CA is responsible for ensuring that certificates are 
issued in accordance with the CP. The CA is also responsible for ensuring that changes in certificate status 
are reflected in its own repositories and those of authorized certificate validation authorities within the 
specified time as stated in the CP. 

The subscribing customer is responsible for protecting the access to the private keys in accordance with the 
terms of the subscriber agreement. This means that any access to the use of the private key is never revealed 
(e.g. PIN to unauthorized users). The subscriber is also required to inform the registration authority or agent if 
they believe that their key has been compromised. 

A relying party should exercise reasonable judgement when deciding whether to rely upon a certificate, but 
must only rely on a certificate that has not been revoked, suspended or expired, notwithstanding when the 
private key was used for the transaction. It also has a duty to ensure compliance with local regulations. 

A8.4 Enforcement 

The CP must state the governing law, applicable contracts or schemes and methods for establishing definitive 
ruling where there are conflicting clauses or there are no documented provisions or set precedents. 
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A.8.5 Liability 

For the purposes of this annex, we will concentrate on the business' liabilities to both the subscriber and the 
relying party. 

The liabilities to the subscriber will always be covered by a contractual relationship. The terms and conditions 
of issue and use of a certificate are covered by the appropriate CP. These will be established before the 
subscriber obtains the certificate and can be designed to ensure that all anticipated liabilities are addressed 
and, if possible, limited. 

The liabilities to the relying party are potentially more complicated. As identified above, the relying party may 
have no contractual relationship with any of the CA/RA/repository but may use the services of a known and 
trusted certificate validation service provider. The following three simple examples serve to illustrate the 
various ways in which liability could be controlled or limited. 

— The CP may identify the circumstances in which the relying party needs to do no more than check the 
validity of the certificate's signature and that it is within its validity period. In such a case, analogous to a 
cheque guarantee card, the authenticity of the certificate is itself sufficient to rely on, although the policy 
may limit the liability on any particular "transaction." The value of the certificate, therefore, is seen by the 
relying party to be in that "guaranteed," yet limited, liability. 

— In other circumstances the CP may require (but cannot force) the relying party to obtain an on-line 
validation of the certificate from the CA/RA (via a repository) before acceptance. In this way the certificate 
acts purely as a means of identification with no inherent value. Each transaction is effectively authorized 
on-line, and there is no liability for unauthorized transactions. 

— Where the relying party has control over the software/environment in which the relying party will use the 
certificate, a relying party agreement can be presented, which must be actively accepted before the 
certificate can be used. Until this becomes a standard means of using certificates and is widely 
implemented in the commercial and freeware products such as browsers and e-mail packages, this will 
not be a reliable way to limit liability. 

A.8.6 Operational requirements 

The following processes with specified timings should be stated: 

— initial registration application including the type of identity credentials; 

— certificate request, issuance and acceptance; 

— certificate validation methods; 

— certificate suspension and revocation together with reasons for certificate revocation and suspension 
(including who authorized, procedures described and notification). 

A statement should be made on how certificate rollover will be managed (e.g. automatic or re-verification of 
identity) or whether new key pairs have to be generated. A statement should also be made on how certificate 
modification, if supported, will be managed (e.g. what authentication procedures are required in order to 
modify the information in an existing certificate). 

The technical security controls may be stated here that detail how the private/public key pair is generated and 
installed and the standards relevant to denote compliance. Controls to manage access to the private key are 
also given together with notification on private key escrow, back-up and archiving. 

The certificate profile should be appended to demonstrate what values should be placed in the respective 
fields and provide guidance on how to determine those values. 
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A.9 Certificate policy management 

The CP must show its unique name, its policy qualifier, the policy version, its status, the policy reference OID 
and its date of issue and, where appropriate, its date of expiry. 

The CP should contain contact details of the policy authority, which include postal address, telephone 
numbers, business operating hours and possibly an e-mail address for customer support. 

Publication and repository contact details should be clearly shown together with methods for clarifying issues 
on: 

— CP administration; 

— confidentiality of policy information; 

— change control process; 

— notification of changes; 

— identification credentials and registration process. 

A CP should have a start date and where possible an expiry date. It may be difficult to manage issued 
certificates with various expiry dates without a policy expiry date. 

It should also state where paper and electronic copies of the CP might be obtained. 

The CP should describe the processes the policy authority invokes to check that a CA's CPS is capable of 
supporting the requirements of the CP. 

The policy authority must ensure that the controls specified in the CA's CPS are appropriate to support the CP. 

A formal method of auditing the CA against its CPS within specified time periods (e.g. two years) should be 
agreed upon between the policy authority and the CA. If the CA wishes to vary the clauses in its CPS then this 
and an agreed method of dispute resolution is advised in order to resolve issues promptly. 
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Annex B 

(informative) 

Elements of a certification practice statement 



B.1 General 

A certification practice statement (CPS) siiouid contain a reference to aii components and sub-components 
contained in tinis annex. 

It is not necessary for a CPS to inciude a definitive statement for every such topic. A particular CPS may state 
"not in practice" for a component, sub-component or element on which the particular CPS imposes no 
requirements. This will indicate to the reader that a conscious decision was made to include or exclude that 
topic. This facilitates comparison of certification practice statements when making decisions on the suitability 
of the practices to business applications. This annex follows the structure of RFC 25271^], which has been 
superseded by RFC 36471'' i]. A table cross-referencing the changes from RFC 2527 to RFC 3647 may be 
found in Annex E. 



B.2 Introduction 

B.2.1 General 

The introduction component of a CPS has the following sub-components: 

— overview; 

— identification; 

— community and applicability; 

— contact details. 

B.2.2 Overview 

This sub-component provides a general introduction (e.g. general purpose of the practice statement). 

B.2.3 Identification 

This sub-component provides any applicable names or other identifiers, including ASN.1 object identifiers. 

B.2.4 Community and applicability 

This sub-component describes the types of entities that issue certificates or that are certified as subject CAs, 
the types of entities that perform RA functions and the types of entities that are certified as subject end entities 
or subscribers. 

NOTE Examples of types of entity for subject CAs are a subordinate organization (e.g., bank, bank branch or division, 
a government agency or department). For example, suppose a bank claims that it issues CA certificates to its branches 
only. Then the user of a CA certificate issued by the bank can assume that the subject CA in the certificate is a branch of 
the bank. Examples of the types of subject RA entities are customer service or data security departments. Examples of 
types of subject end entities are retail or wholesale bank customers, cardholders, individual investors, policyholders and 
employees. 

78 



IS/ISO 21188: 2006 



This sub-component also contains: 

— a iist of applications for which the issued certificates are suitable; 

— a list of applications for which use of the issued certificates is limited, or a list of applications for which use 
of the issued certificates is prohibited. 

B.2.5 Contact details 

This sub-component includes the name and mailing address of the authority that is responsible for the 
registration, maintenance and interpretation of this CPS. It also includes the name, electronic mail address, 
telephone number and fax number for all appropriate contact persons. 

B.3 General provisions 

B.3.1 General 

This component specifies any applicable presumptions on a range of legal and general practice topics, 
including: 

— obligations; 

— liability; 

— interpretation and enforcement; 

— publication and repositories; 

— compliance audit; 

— confidentiality. 

Each sub-component may need to separately state provisions applying to the entity types: CA, repository, RA, 
subscriber and relying party. 

B.3.2 Obligations 

This sub-component contains, for each entity type, any applicable provisions regarding the entity's obligations 
to other entities. Such provisions may include: 

— CA and/or RA or certificate status provider obligations: 

— notification of issuance of a certificate to the subscriber who is the subject of the certificate being 
issued; 

— notification of issuance of a certificate to parties other than the subject of the certificate; 

— notification of revocation or suspension of a certificate to the subscriber whose certificate is being 
revoked or suspended; 

— notification of revocation or suspension of a certificate to parties other than the subject whose 
certificate is being revoked or suspended; 

— subscriber obligations: 

— accuracy of representations in certificate application; 
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— protection of the entity's private key; 

— protection of tine meclnanism to enabie tine use of the private key (i.e., cardholder verification 
method); 

— restrictions on private key and certificate use; 

— notification upon private key compromise; 

— relying party obligations: 

— purposes for which certificate is used; 

— digital signature verification responsibilities; 

— revocation and suspension checking responsibilities; 

— acknowledgment of applicable liability caps and warranties; 

— repository obligations; 

— timely publication of certificates and revocation information; 

— certificate status provider: 

— to make validation service available and responsive within service level agreement levels; 

— to validate certificate accurately. 

B.3.3 Liability 

This sub-component contains, for each entity type, any applicable provisions regarding apportionment of 
liability, such as: 

— warranties and limitations on warranties; 

— kinds of damage covered (e.g. indirect, special, consequential, incidental, punitive, liquidated damage, 
negligence and fraud) and disclaimer; 

— loss limitations (caps) per certificate or per transaction; 

— other exclusions (e.g. acts of God, other party responsibilities). 

B.3.4 Interpretation and enforcement 

This sub-component contains any applicable provisions regarding interpretation and enforcement of the CP or 
CPS, addressing such topics as: 

— corporate security policy and procedures; 

— governing law; 

— severance of provisions, survival, merger, and notice; 

— dispute resolution procedures. 
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B.3.5 Publication and repositories 

This sub-component contains any applicable provisions regarding: 

— CA obligations to mal<e available information regarding its practices, its certificates and the current status 
of such certificates; 

— frequency of publication; 

— classification of published information including CP definitions, CPS, certificates, certificate status and 
CRLs; 

— requirements pertaining to the use of repositories including online certificate status verification (if 
supported). 

B.3.6 Compliance audit 

This sub-component addresses the following: 

— frequency of compliance audit for each entity; 

— auditor's relationship to the entity being audited (i.e., a statement that the auditor must be independent); 

— general list of topics covered under the compliance audit including CA environmental controls, key 
management controls and certificate life cycle management controls. 

B.3.7 Confidentiality 

This sub-component addresses the following: 

— types of information that should be l<ept confidential by CA or RA; 

— types of information that are not considered confidential; 

— who is entitled to be informed of reasons for revocation and suspension of certificates; 

— policy on release of information to law enforcement officials; 

— information that may be revealed as part of civil discovery to conform with regulatory requirements; 

— conditions upon which CA or RA may disclose and to whom upon owner's request; 

— any other circumstances under which confidential information may be disclosed. 

B.4 Identification and authentication 

B.4.1 General 

This component describes the procedures used to authenticate a certificate applicant to a CA or RA prior to 
certificate issuance. It also describes how parties requesting re-key or revocation are authenticated. This 
component also addresses naming practices, including name ownership recognition and name dispute 
resolution. 

This component has the following sub-components: 

— initial registration; 
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— routine re-key; 

— re-key after revocation; 

— revocation request; 

— suspension request. 

B.4.2 Initial registration 

Tinis sub-component inciudes tine foiiowing eiements regarding identification and autinentication procedures 
during entity registration or certificate issuance: 

— types of names assigned to the subject; 

NOTE 1 Examples include X.500 distinguished name, Internet e-mail address and URL. 

— whether names have to be meaningfui or not; 

NOTE 2 The term "meaningful" means that the name form has commonly understood semantics to determine identity 
of the person and/or organization. Directory names and RFC 8221^1 names may be more or less meaningful. 

— ruies for interpreting various name forms; 

— whether names have to be unique; 

— how name claim disputes are resoived; 

— recognition, authentication, and roie of trademarks; 

— if and how the subject shouid prove possession of the companion private key for the pubiic key being 
registered; 

NOTE 3 Examples of proof include the issuing CA generating the key, or requiring the subject to send an electronically 
signed request or to sign a challenge. 

— authentication requirements for organizationai identity of subject (CA, RA or end entity); 

NOTE 4 Types of organization identity authentication include articles of incorporation, duly signed corporate resolutions, 
company seal and notarized documents. 

— authentication requirements for a person acting on behaif of a subject (CA, RA or end entity); 

NOTE 5 Types of individual identity authentication include physical recognition, knowledge of an individual, 
identification card biometrics (thumb print, ten fingerprint, face, palm and retina scan), driving license, passport, voice 
recognition or an established employee authentication method. 

— number of pieces of identification evidence required; 

— how a CA or RA vaiidates the pieces of identification evidence provided as genuine: aiternativeiy the 
procedures for achieving this remoteiy; 

— if the individuai must present personaiiy to the authenticating CA or RA; 

— how an individuai as an organizationai representative is authenticated and whether they are authorized 
(mandated) by the company to act on its behaif. 

NOTE 6 Examples include duly signed authorization papers or corporate ID badge. 
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B.4.3 Routine re-key 

This sub-component describes the identification and authentication procedures for routine re-l<eying for each 
subject type (CA, RA and end entity). 

NOTE The identification practice for routine re-key should be the same as the one for initial registration unless the 

expiring certificate is used for authentication prior to its expiration date. The re-key authentication may be accomplished 
using the techniques for initial identification and authorization or using digitally signed requests. 

B.4.4 Re-key after revocation — No key compromise 

This sub-component describes the identification and authentication procedures for re-key for each subject 
type (CA, RA, CVSP and end entity) after the subject certificate has been revoked. If a certificate has been 
revoked then its status must not be changed. 

NOTE This identification and authentication practice should be the same as that for initial registration. 

B.4.5 Revocation request 

This sub-component describes the identification and authentication procedures for a revocation request by 
each subject type (CA, RA and end entity) or other authorized party (as stated in the CP) or by a regulatory 
authority. 

NOTE The identification practices for revocation request could be the same as that for initial registration since the 

same subject certificate needs to be revoked. The authentication practices could accept a revocation request digitally 
signed by subject. The authentication information used during initial registration could be acceptable for revocation request. 
Other less stringent authentication practices could be defined. 

B.4.6 Suspension request 

This sub-component describes the identification and authentication procedures for a suspension request by 
each subject type (CA, RA and end entity) or other authorized party (as stated in the CP) or by a regulatory 
authority. 

NOTE The identification practices for suspension request could be the same as that for initial registration since the 

same subject certificate needs to be suspended. The authentication practices could accept a suspension request digitally 
signed by subject. The authentication information used during initial registration could be acceptable for suspension 
request. Other less stringent authentication practices could be defined. 



B.5 Operational requirements 

B.5.1 General 

This component is used to specify requirements imposed upon issuing CA, subject CAs, RAs, CVSP or end 
entities with respect to various operational activities. 

This component consists of the following sub-components: 

— certificate application; 

— certificate issuance; 

— certificate acceptance; 

— certificate validation; 

— certificate suspension and revocation; 
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— security audit procedures; 

— records arcinivai; 

— key cinangeover; 

— compromise and disaster recovery; 

— CA termination. 

Witinin eacin sub-component, separate consideration may need to be given to issuing CA, repository, subject 
CAs, RAs and end entities. 

B.5.2 Certificate application 

TInis sub-component is used to state requirements regarding subject enroiment and request for certificate 
issuance. 

B.5.3 Certificate issuance 

This sub-component is used to state requirements regarding issuance of a certificate and notification to tine 
appiicant of sucin issuance. 

B.5.4 Certificate acceptance 

TInis sub-component is used to state requirements regarding acceptance of an issued certificate and for 
consequent pubiication of certificates. 

B.5.5 Certificate suspension, revocation, and status management 

This sub-component addresses the foiiowing: 

— conditions to be fuifiiied under which a certificate may be revol<ed; 

— who can request the revocation of the entity certificate; 

— procedures used for certificate revocation request; 

— revocation request grace period, if any, avaiiabie to the subject; 

— conditions to be fuifiiied under which a certificate may be suspended; 

— who can request the suspension of a certificate; 

— procedures to request certificate suspension; 

— how iong the suspension may iast; 

— conditions to be fuifiiied under which a suspended certificate may be returned to a iive status; 

— if a CRL mechanism is used, the issuance avaiiabiiity and frequency of updates; 

— requirements on reiying parties to checl< CRLs; 

— on-line status checking avaiiabiiity and guaranteed response times; 
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— requirements on relying parties to perform on-iine status cinecks; 

— requirements on tine certificate status provider to enable the authentication of a status response to a 
relying party; 

— other forms of official suspension, revocation or certificate status notices available; 

— a requirement on validation authorities and relying parties to check other forms of official suspension, 
revocation or certificate status notices; 

— any variations on the above stipulations when the suspension or revocation is the result of private key 
compromise (as opposed to other reasons for suspension or revocation). 

B.5.6 Security audit procedures 

This sub-component is used to describe event logging and audit systems. Elements include the following: 

— types of event recorded; 

NOTE Example of audit events include requests to create a certificate, requests to suspend or revoke a certificate, 

key compromise notification, creation of a certificate, revocation of a certificate, issuance of a certificate, issuance of a 
CRL, issuance of key compromise CRL, establishment of trusted roles on the CA, actions of trusted personnel, changes to 
CA keys, etc. 

— frequency with which audit logs are processed or audited; 

— period for which audit logs are kept; 

— protection of audit logs; 

— who can view audit logs and under what authority; 

— protection against modification of audit log; 

— protection against deletion of audit log; 

— audit log back-up procedures; 

— whether the audit log accumulation system is internal or external to the entity; 

— whether the subject who caused an audit event to occur is notified of the audit action; 

— vulnerability assessments. 

B.5.7 Records archival 

This sub-component is used to describe general records archival (or records retention) policies, including the 
following: 

— types of event recorded; 

NOTE Example of archive events are: requests to create a certificate, requests to revoke a certificate, key 

compromise notification, creation of a certificate, revocation of a certificate, issuance of a certificate, issuance of a CRL, 
issuance of key compromise CRL and changes to CA keys. 

— retention period for archive; 
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— protection of archive: 

— wino can view the archive; 

— protection against modification of archive; 

— protection against deietion of archive; 

— archive bacl<-up procedures; 

— requirements for time-stamping of records; 

— whether the archive coiiection system is internai or externai; 

— procedures to obtain and verify archive information. 

B.5.8 Key changeover 

This sub-component describes the procedures to provide a new pubiic key to a CA user. 

B.5.9 Compromise and disaster recovery 

This sub-component describes requirements reiating to notification and recovery procedures in the event of 
compromise or disaster. Each of the foiiowing circumstances may need to be addressed separateiy. 

— The recovery procedures used if computing resources, software, and/or data are corrupted or suspected 
of being corrupted: these procedures describe how a secure environment is re-estabiished, which 
certificates are revol<ed, whether the entity l<ey is revol<ed, how the new entity pubiic key is provided to 
the users and how the subjects are recertified. 

— The recovery procedures used if the entity pubiic key is revoked: these procedures describe how a 
secure environment is re-estabiished, how ttie new entity pubiic key is provided to the users, and how the 
subjects are recertified. 

— The recovery procedures used if the entity key is compromised: these procedures describe how a secure 
environment is re-estabiished, how the new entity's pubiic key is obtained and how the entity is recertified. 

B.5.10 CA termination 

This sub-component describes requirements reiating to procedures for termination and for notification of 
termination of a CA or RA, inciuding the identity of the custodian of CA and RA archivai records. 
Consideration shouid be given to what information shouid be retained from a reguiatory and risk perspective. 

B.6 Physical, procedural and personnel security controls 

B.6.1 General 

This component describes physicai, procedurai and personnei controis used by the issuing CA to perform 
secureiy the functions of key generation, subject authentication, certificate issuance, certificate revocation, 
audit and archivai. 

This component can aiso be used to define controis on repository, subject CAs, RAs and end entities. The 
controis for the subject CAs, RAs, and end entities may vary by entity. 
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These controls are crucial to trusting the certificates since lack of physical, procedural, and personnel security 
may compromise CA operations resulting, for example, in the creation of certificates or CRLs with erroneous 
information or the compromise of the CA private key. 

This component consists of three sub-components: 

— physical security controls; 

— procedural controls; 

— personnel security controls. 

Within each sub-component, separate consideration will, in general, need to be given to each entity type, 
i.e., issuing CA, repository, subject CAs, RAs and end entities. 

B.6.2 Physical security controls 

In this sub-component, the physical controls on the facility housing the entity systems are described. 

NOTE Examples of physical access controls are: monitored facility, guarded facility, locked facility, access controlled 

using tokens, access controlled using biometrics and access controlled through an access list. 

Topics addressed may include: 

— site location and construction; 

— physical access; 

— cryptographic hardware; 

— power and air conditioning; 

— water exposures; 

— fire prevention and protection; 

— electro-magnetic protection; 

— media storage; 

— waste disposal; 

— off-site back-up. 

B.6.3 Procedural controls 

In this sub-component, requirements for recognizing trusted roles are described, together with the 
responsibilities for each role. 

NOTE Examples of the roles include system administrator, system security officer and system auditor. The duties of 

the system administrator are to configure, generate, boot and operate the system. The duties of the system security officer 
are to assign accounts and privileges. The duties of the system auditor are to set up system audit profile, perform audit file 
management and conduct audit review. 

For each task identified for each role, it should also be stated how many individuals are required to perform 
the task {n out of m rule). Identification and authentication requirements for each role may also be defined. 
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B.6.4 Personnel security controls 

This sub-component addresses the following: 

— background checl<s and clearance procedures required for the personnel filling the trusted roles; 

NOTE 1 The background checks may include clearance level (e.g. none, sensitive, confidential, secret, top secret, etc.) 
and the clearance granting authority name. In lieu of or in addition to a defined clearance, the background checks may 
include types of background information (e.g. name, place of birth, date of birth, home address, previous residences, 
previous employment and any other information that may help determine trustworthiness). The description should also 
include which information was verified and how. 

— background checks and clearance procedures requirements for other personnel, including janitorial staff; 

NOTE 2 For example, the CP may impose personnel security requirements on the network system administrator 
responsible for a CA network access. 

— training requirements and training procedures for each role; 

— disciplinary procedures to be followed as a result of unauthorized actions, unauthorized use of authority, 
and unauthorized use of entity systems by personnel; 

NOTE 3 Each authorized person should be accountable for his/her actions. 

— controls on contracting personnel; 

— documentation (e.g. operations or training manual) to be supplied to personnel. 

B.7 Technical security controls 

B.7.1 General 

This component is used to define the security measures taken by the issuing CA to protect its cryptographic 
keys and activation data (e.g. PINs, passwords, or manually held key shares). This component may also be 
used to Impose constraints on registration authorities, repositories, subject CAs and end entitles to protect 
their cryptographic keys and crucial security parameters. Secure key management Is crucial to ensure that all 
secret and private keys and activation data are protected and used only by authorized personnel. 

This component also describes other technical security controls used by the issuing CA to perform securely 
the functions of key generation, user authentication, certificate registration, certificate revocation, audit and 
archival. Technical controls include life-cycle security controls (Including software development environment 
security, trusted software development methodology) and operational security controls. 

This component can also be used to define other technical security controls on repositories, subject CAs, RAs 
and end entitles. 

This component has the following sub-components: 

— key pair generation and Installation; 

— private key protection in its storage and use; 

— distribution of the private key where created by the CA or card bureau; 

— other aspects of key pair management; 

— activation data; 
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— computer security controls; 

— life cycle security controls; 

— network security controls; 

— cryptographic module engineering controls. 

B.7.2 Key pair generation and installation 

Key pair generation and installation need to be considered for the issuing CA, repositories, subject CAs, RAs 
and subject end entities. For each of these types of entity, the following questions potentially need to be 
answered. 

— Who generates the end entity's public, private key pair? 

— How is the private key stored and provided securely to the end entity? 

— How is the entity's public key provided securely to the certificate manufacturer? 

— If the entity is a CA or certificate status provider (issuing or subject) how is the entity's public key 
certificate securely provided to the end entities? 

— What are the algorithms used and what are key sizes? 

— Who generates the public key parameters? 

— Is the quality of the parameters checked during key generation? 

— Is the key generation performed in hardware or software? 

— For what purposes may the key be used, or for what purposes should usage of the key be restricted? (For 
X.509 certificates, these purposes should map to the key usage flags in the Version 3, X.509 certificates.) 

B.7.3 Private key protection 

Requirements for private key protection need to be considered for the issuing CA, repositories, subject CAs, 
RAs and subject end entities. For each of these types of entity, the controls requirements may be different and 
to enable this to be determined the following questions potentially need to be answered. 

— What standards, if any, are required for the module used to generate the keys? For example, are the keys 
certified by the infrastructure required to be generated using a module complaint with the FIPS 140-2? If 
so, what is the required FIPS 140-2 level of the module? 

— Is the private key under « out of m multi-person control? If yes, provide n and m (two-person control is a 
special case of n out of m, where n = m=2). 

NOTE 1 The n out of m rule allows a key or key activation data to be split in m parts. The m parts may be given to m 
different individuals. Any n parts out of the m parts may be used to fully reconstitute the key, but having any 71-I parts 
provides one with no information about the key. 

— Is the private key escrowed? If so, who is the escrow agent, what form is the key escrowed in (examples 
include plaintext, encrypted, split key), and what are the security controls on the escrow system? 

NOTE 2 A key may be escrowed, backed up or archived. Each of these functions has different purpose. Thus, a key 
may go through any subset of these functions depending on the requirements. The purpose of escrow is to allow a third 
party (such as an organization or government) to legally obtain the key without the cooperation of the subject. The 
purpose of back up is to allow the subject to reconstitute the key in case of the destruction of the key. The purpose of 
archive is to provide for re-use of the key in future (e.g. use the private key to decrypt a document). 
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Is the private key backed up? If so, who is the back-up agent, what form is the key backed up in 
(examples include plaintext, encrypted, split key), and what are the security controls on the back-up 
system? 

Is the private key archived? If so, who is the archival agent, what form is the key archived in (examples 
include plaintext, encrypted, split key), and what are the security controls on the archival system? 

Who enters the private key in the cryptographic module? In what form (i.e., plaintext, encrypted or split 
key)? How is the private key stored in the module (i.e., plaintext, encrypted or split key)? 

Who can activate (use) the private key? What actions must be performed to activate the private key 
(e.g. login, power on, supply PIN, insert token/key, automatic, etc.)? Once the key is activated, is the key 
active for an indefinite period, active for one time or active for a defined time period? 

Who can de-activate the private key and how? Examples of how might include logout, power off, remove 
token/key, automatic or time expiration. 

Who can destroy the private key and how? Examples of how might include token surrender, token 
destruction or key overwrite. 



B.7.4 Other aspects of key pair management 



Other aspects of key management need to be considered for the issuing CA, repositories, subject CAs, RAs 
and subject end entities. For each of these types of entity, the following questions potentially need to be 
answered. 

— Is the public-key archived? If so, who is the archival agent and what are the security controls on the 
archival system? The archival system should provide integrity controls other than digital signatures since 
the archival period may be greater than the cryptanalysis period for the key and the archive requires 
tamper protection, which is not provided by digital signatures. 

— What are the usage periods, or active lifetimes, for the public and the private key respectively? 

B.7.5 Activation data 

Access to the private key needs to be protected initially and throughout its continued use while it is still valid. 
Activation data is used in the authentication mechanism to validate the private key owner. Activation data refer 
to data values other than keys that are required to operate cryptographic modules and that need to be 
protected. Protection of activation data potentially needs to be considered for the issuing CA, subject CAs, 
RAs and end entities. Such consideration potentially needs to address the entire life cycle of the activation 
data from generation through archival and destruction. For each of the entity types (issuing CA, repository, 
subject CA, RA and end entity) all of the questions listed in B.7.2 to B.7.4 potentially need to be answered with 
respect to activation data rather than with respect to keys. 

NOTE Examples of activation data are a PIN, pass phrase or biometric. 

B.7.6 Computer security controls 

This sub-component is used to describe computer security controls such as: use of the trusted computing 
base concept, discretionary access control, labels, mandatory access controls, object re-use, audit, 
identification and authentication, trusted path, security testing and penetration testing. Product assurance may 
also be addressed. 

B.7.7 Life cycle security controls 

This sub-component addresses system development controls and security management controls. 
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System development controls include development environment security, development personnel security, 
and configuration management security during product maintenance, software engineering practices, software 
development methodology, modularity and layering, use of failsafe design and implementation techniques 
(e.g. defensive programming) and development facility security. 

Security management controls include execution of tools and procedures to ensure that the operational 
systems and networks adhere to configured security. These tools and procedures include checking the 
integrity of the security software, firmware and hardware to ensure their correct operation. 

B.7.8 Network security controls 

This sub-component addresses network security related controls, including firewalls. 

B.7.9 Cryptographic mechanism engineering controls 

This sub-component addresses the following aspects of a cryptographic module: identification of the 
cryptographic module boundary, input/output, roles and services, finite state machine, physical security, 
software security, operating system security, algorithm compliance, electromagnetic compatibility and self 
tests. Requirements may be expressed through reference to a standard such as FIPS 140-2. 

NOTE A cryptographic mechanism is a combination of hardware and software and, where specific devices are used, 

associated firmware. The compliance description should be specific and detailed. For example, for each FIPS 140-2 
requirement, describe the level and state whether an accredited laboratory has certified the level. 

B.8 Certificate and CRL profiles 

B.8.1 General 

This component is used to specify the certificate format and, if CRLs are used, the CRL format. Assuming use 
of the X.509 certificate and CRL formats, this includes information on profiles, versions and extensions used 
and whether they need to be digitally signed. 

This component has three sub-components: 

— certificate profile; 

— CRL profile; 

— OCSP profile. 

B.8.2 Certificate profile 

This sub-component addresses such topics as the following: 

— version number(s) supported; 

— certificate extensions populated and their criticality; 

— cryptographic algorithm object identifiers; 

— name forms used for the CA, RA and end entity names; 

— name constraints used and the name forms used in the name constraints; 

— applicable certificate policy object identifier(s); 
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— usage of the policy constraints extension; 

— policy qualifiers syntax and semantics; 

— processing semantics for the critical certificate policy extension; 

— contents and usage of non-standard extensions. 

B.8.3 CRL profile 

This sub-component addresses such topics as the following: 

— version numbers supported for CRLs; 

— the availability and frequency of CRL updates; 

— whether the CRLs require to be digitally signed; 

— CRL and CRL entry extensions populated and their criticality. 

B.8.4 OCSP profile 

If applicable, this sub-component addresses such topics as the following: 

— OCSP request requirements; 

— definitive response message requirements; 

— the availability and guaranteed response times; 

— whether the status responses require to be digitally signed; 

— error message requirements. 

B.9 Practices administration 

B.9.1 General 

This component is used to specify how practices will be maintained. 
It contains the following sub-components: 

— change procedures; 

— publication and notification procedures; 

— CP compliance. 

B.9.2 Change procedures 

It will occasionally be necessary to change certificate policies and certification practice statements. Some of 
these changes will not materially reduce the assurance that a CP or its implementation provides, and will be 
judged by the policy administrator as not changing the acceptability of certificates asserting the policy for the 
purposes for which they have been used. Such changes to certificate policies and certification practice 
statements need not require a change in the CP object identifier or the CPS pointer (URL). Other changes to a 

92 



IS/ISO 21188: 2006 



CP and CPS will change the acceptability of certificates for specific purposes, and these changes will require 
changes to the CP object identifier or CPS pointer (URL). 

This sub-component contains the following information. 

— A list of components, sub-components, and/or elements thereof that can be changed without notification 
and without changes to the CP object identifier or CPS pointer (URL). 

— A list of components, sub-components, and/or elements thereof that may change following a notification 
period without changing the CP object identifier or CPS pointer (URL). The procedures to be used to 
notify interested parties (relying parties, certification authorities, etc.) of the CP or certification practice 
statement changes are described. The description of notification procedures includes the notification 
mechanism, notification period for comments, mechanism to receive, review and incorporate the 
comments, mechanism for final changes to the policy and the period before final changes become 
effective. 

— A list of components, sub-components, and/or elements, changes to which require a change in CP object 
identifier or CPS pointer (URL). 

B.9.3 Publication and notification procedures 

This sub-component contains the following elements: 

— a list of components, sub-components, and elements thereof that exist but that are not made publicly 
available; 

NOTE An organization may choose not to make public some of its security controls, clearance procedures or some 

others elements, due to their sensitivity. 

— descriptions of mechanisms used to distribute the CP or mal<e it available, including access controls. 

B.9.4 CP compliance 

This sub-component describes the processes to checl< that a CPS complies with the requirements of the CP. 
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Annex C 

(informative) 

Object identifiers (OID) 



C.1 Why have an OID? 

An OID is required so tinat reiying party software can mecinanicaiiy identify a OP (e.g. tine OP document 
applicable to the root CA, which establishes one or more of the policy domains). Each subordinate GA would 
need an OID to identify their GPS. 



C.2 What is an OID? 

An object identifier (OID) is a unique series of integers that unambiguously identifies an information object. 
The ASN.1 standards define an information object as a "well-defined piece of information, definition or 
specification which requires a name in order to identify its use in an instance of communication." Object 
identifiers can be used to provide a name for anything, including a GP, GPS, cryptographic algorithm, 
business, organization, file format, role, product, device, document version or standard. 

The ISO/TG 68 organization is identified by the object identifier value 1.3.133. This value is the TG 68 "arc", 
the OID value which TG 68 controls as registrar and under which TG 68 is authorized by ISO to assign object 
identifiers. TG 68 member countries are identified under the OID 1 .3.1 33.1 6, and each TG 68 member country 
has been assigned their own OID, for which they are the solely responsible registrar. OlDs may be obtained 
from the TG 68 Secretariat or from member countries that elect to assign values. 

The set of all TG 68 standards is identified by the OID 1.3.133.17. This document is identified by the OID 
value 1.3.133.17.21188. OlDs may be communicated in any number of ways, by voice, by handwriting on 
paper or by a computer program, so the form of representation of these values can vary widely. The OID for 
this document may be represented in a binary format convenient for use by an application program, or 
represented using the ASN.1 basic value notation as "iso(1) identified-organization(3) tc68(133) standard(17) 
pki-cp-cps(21188)", or represented using the ASN.1 XML value notation as the XML markup value "<pki-cp- 
cps> 1.3.133.17.21188 </pki-cp-cps>". 

It is envisaged that policy OlDs will be embedded in digital certificates so that PKI service providers, end 
entities, and others can determine the set of rules under which an issuer/certificate manufacturer has 
generated a certificate. A standard set of GP OlDs could enable the automated processing of policy and 
practice information by digital certificate application programs. An object identifier should be obtained and 
registered for each certificate policy to uniquely identify that certificate policy. The typical way to obtain an OID 
is to go to the appropriate national registration authority for OlDs. 

C.3 Registration of OlDs 

Recommendation X.660 of ISO/IEG 9834-1:1993 defines the general procedures for the operation of 
registration authorities. The current International Standard was approved jointly by the International 
Organization for Standardization (ISO), the International Electrotechnical Commission (lEG) and the 
International Telecommunication Union (ITU). 

These international standards organizations control all of the top level OID arcs, the values that may appear in 
the first position of any OID integer series. These values are represented as the OID values itu-t(O), "iso(1)" 
and "joint-iso-itu-t(2)" and form the root of a registration-hierarchical-name-tree (RH-name-tree) of all possible 
OID values. The leaf and non-leaf nodes of this tree correspond to objects that are registered. Non-leaf nodes 
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correspond to registration autlnorities winose registration responsibiiity Inas been deiegated to tinem by tineir 
superior node. 

Tine international standards organizations delegate tine management of assigned arcs to other responsible 
bodies who serve as registrars. ISO has done so by assigning an arc to TC 68. To guarantee that no OID was 
assigned more than once, TC 68 then designed a schema for managing the OlDs that it would assign under 
its arc. TC 68 then formed an object identifier tree by assigning OID values under its arc. It chose to delegate 
management of registration responsibility to nodes under its arc by assigning an arc to each of its member 
countries. This ensures that OID assignments by member countries are unique and never collide with 
assignments made by other registration authorities, and that each member country can assign OlDs 
independent of TC 68 and of all other member countries. 



C.4 Why do you need an OID and how should they be managed? 

An OID plus other components are used to manage access to directory resources. The OID is also embedded 
in a certificate extension. However, a challenging issue is how to manage change to the CP document. As a 
hash is involved, each time the CP document is changed then the OID that names the CP document could be 
changed. This is not very satisfactory. Alternatively, as the hash identifies the version of the CP document, 
then the same OID could be kept, and the hash changed. 
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Annex D 

(informative) 

CA key generation ceremony 



D.1 General 

This annex provides an overview of tlie requirements for conducting a CA l<ey generation ceremony. Tiiis is 
particularly relevant for the root CA. 



D.2 Roles and responsibilities 

D.2.1 General 

CA l<ey generation ceremony roles generally include the following: 

— operating system administrator; 

— CA application administrator; 

— cryptographic materials custodian; 

— key share holders; 

— master of ceremonies; 

— policy authority; 

— independent observer. 

Additional roles may be required, depending on the specific hardware and software components implemented 
by the organization, the PKI architecture, and the CPS requirements. Additional roles may be required for CA 
operations, following the completion of the CA key generation ceremony. 

D.2.2 Operating system administrator 

Major responsibilities are to: 

— install and configure the operating system in accordance with the CA key generation ceremony script; 

— establish operating system user accounts; 

— control the operating system root or administrator password. 

D.2. 3 CA application administrator 

Major responsibilities are to: 

— install and configure the CA application in accordance with the CA key generation ceremony script; 

— establish CA application user accounts. 
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D.2.4 Cryptographic materials custodian 

Major responsibilities are to: 

— maintain an accurate inventory of CA key generation ceremony materials including storage locations; 

— maintain an accurate inventory of CA activation materials and shareholder assignments; 

— ensure that ceremony materials are sealed in tamper-evident packaging; 

— ensure that ceremony materials are securely stored following the ceremony. 

D.2.5 Key share holders 

Major responsibilities are to: 

— take custodianship of assigned CA activation materials, e.g. tokens, smart cards or passphrases required 
to activate hardware security modules that protect the CA private key; 

— safeguard assigned CA activation materials. 

D.2.6 Master of ceremonies 

Major responsibilities are to: 

— coordinate the CA key generation ceremony and ensure that procedures defined in the CA key 
generation ceremony script are followed consistently; 

— record any deviations from the CA key generation ceremony script and record any incidents that occur 
during the ceremony; 

— approve any significant deviations from the CA key generation ceremony script, with input from the policy 
authority as appropriate. 

D.2.7 Policy authority 

Major responsibilities are to: 

— authorize the conduct of the CA key generation ceremony; 

— approve the assignment of CA key generation ceremony roles. 

D.2.8 Independent observer 

Major responsibilities are to: 

— witness the CA key generation ceremony; 

— attest as to whether the key generation ceremony script was followed with any exceptions recorded, 
e.g. by signing off on the script or providing an opinion in a separate report). 

The independent observer should be independent of the entities responsible for the CA key generation 
ceremony and ongoing CA operations. This role could be filled by an internal auditor, external auditor or other 
independent party. The independent observer should be knowledgeable with regard to CA key generation 
ceremony requirements and PKI. 
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D.3 CA key generation ceremony script 

The CA key generation ceremony should be performed in accordance with the requirements of the CPS and a 
detailed CA l<ey generation ceremony script. While the details of the script will vary depending on the 
technologies implemented and the PKI architecture, a CA key generation ceremony script should address the 
following elements: 

— CA key generation ceremony roles and responsibilities (see D.2); 

— CA key generation ceremony environment, including: 

— physical security requirements for the ceremony location; 

— participant sign-in and sign-out procedures; 

— CA key generation ceremony procedures (see D.4); 

— post-ceremony storage of cryptographic materials, including: 

— designation of materials for storage at specific secure storage locations; 

— procedures for transport of materials to off-site or disaster recovery storage locations. 

D.4 CA key generation ceremony procedures 

While the specific procedures will vary by implementation, the following procedures should be included within 
this component of the script. 



Phase 


Description 


1. Hardware preparation 


The PKI administrator should prepare the hardware platform. The following, at a 
minimum, should be undertaken: 

a) Inspect the CA machine for any obvious evidence of tampering. 

b) Confirm that only those hardware components specified in the system 
specification are present. 

c) The CA must not be connected to any external systems or network. 

d) Confirm that the hard disk that was formatted was the only hard disk 
connected to the system. 

e) Record any issues on an exception form. 

f) Provide removable media to enable CA certificate request and 
distribution (if applicable). 


2. Operating system 
installation 


The operating system administrator should install and configure the operating 
system following the procedures specified in the CA key generation ceremony 
script. 


3. CA application 
installation 


The CA application administrator should prepare the software system. The 
following, at a minimum, should be undertaken: 

a) Install the CA application software and other required applications 
(e.g. HSM manager software, database, etc.). 

b) Confirm that software only comes from trusted source on trusted media. 

c) Confirm event logging is active. 

d) Record any issues on an exception form. 
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Phase 


Description 


4. CA application 
configuration 


The CA application should be configured in accordance with the script. This 
includes, for example, establishing CA application user accounts, configuring 
logging, configuring certificate profiles, configuring the hardware security module, 
and configuring of "m of n" requirements. For a root CA, a minimum value of three 
is recommended form (i.e., three people). 


5. CA l<ey generation 


The CA key pair is generated in accordance with the procedures detailed in the 
script. This step may require the participation of multiple key share holders 
depending on how the organization has chosen to configure the hardware security 
module. For business continuity purposes, the organization should consider 
generating a secondary root CA as described in Annex J of ISO 15782-1 :2003. 


6. CA key back-up 


For business continuity purposes, one or more back-up copies of the CA private 
key are typically created and stored at separate locations. The script should 
describe the relevant procedures for doing so. 


7. CA certificate signing 


For root CAs, the ceremony should include the creation of a self-signed root CA 
certificate for distribution to end users. For subordinate CAs, the ceremony should 
include the generation of a certificate request, delivery of the request to the parent 
CA, and signing of the subordinate CA certificate by the parent CA. 

A hash of the root CA certificate should be created using an approved algorithm 
for later distribution to enable users to verify the authenticity of the root CA 
certificate. 


8. CA system sinutdown 


The CA system should be backed up and then closed down. The CA system 
should then be moved to a properly secured facility in accordance with the script. 
For certain root CA systems, it may be desirable to completely erase the software 
system (including the operating system) from the hard disk. The system may 
require rebuilding if further CA operations are required. 


9. Preparation of 
materials for storage 


All ceremony information should be prepared for archiving. This should include a 
back-up of the CA system, a written record of the ceremony (i.e., the signed-off 
script) and event logs. 

Cryptographic materials (including hardware security modules and activation 
materials) should also be prepared for storage at predetermined secure storage 
locations. 
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Annex E 

(informative) 

Mapping of RFC 2527 to RFC 3647 



The following matrix maps the sections of RFC 2527 to the new sections in its successor RFC 3647. 



RFC 2527 Section 


RFC 3647 Section 


1. Introduction 


1. 


1.1 Overview 


1.1 


1.2 Identification 


1.2 


1 .3 Community and Applicability 


1.3 


1.3.1 Certification Authorities 


1.3.1 


1.3.2 Registration Authorities 


1.3.2 


1.3.3 End Entities 


1.3.3, 1.3.4 


1.3.4 Applicability 


1.4,4.5 


1 .4 Contact Details 


1.5 


1.4.1 Specification Administration Organization 


1.5.1 


1.4.2 Contact Person 


1.5.2 


1.4.3 Person Determining CPS Suitability for the Policy 


1.5.3 


2. General Provisions 


2,8,9 


2.1 Obligations 


2.6.4 


2.1.1 CA Obligations 


Various 


2.1.2 RA Obligations 


Various 


2.1.3 Subscriber Obligations 


4.1.2,4.4,4.5,4.5.1,4.6.5,4.7.5, 
4.8.1,4.8.5,4.9.1,4.9.2,4.9.13, 
4.9.15, 5., 6., 9.6.3, 9.9 


2.1.4 Relying Party Obligations 


4.5, 4.5.2, 4.9.6, 5., 6., 9.6.4, 9.9 


2.1 .5 Repository Obligations 


2.,4.4.2, 4.4.3, 4.6.6, 4.6.7,4.7.6, 
4.7.7,4.8.6,4.8.7 


2.2 Liability 


9.6,9.7,9.8,9.9 


2.2.1 CA Liability 


9.6.1,9.7,9.8,9.9 


2.2.2 RA Liability 


9.6.2,9.7,9.8,9.9 


2.3 Financial Responsibility 


9.2 


2.3.1 Indemnification by Relying Parties 


9.9 


2.3.2 Fiduciary Relationships 


9.7 


2.4 Interpretation and Enforcement 


9.16 


2.4.1 Governing Law 


9.14,9.15 


2.4.2 Severability, Survival, Merger, Notice 


9.10.3,9.11,9.16.1,9.16.3 
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RFC 2527 Section 


RFC 3647 Section 


2.4.3 Dispute Resolution Procedures 


9.13,9.16.4 


2.5 Fees 


9.1 


2.5.1 Certificate Issuance or Renewal Fees 


9.1.1 


2.5.2 Certificate Access Fees 


9.1.2 


2.5.3 Revocation or Status Information Access Fees 


9.1.3 


2.5.4 Fees for Other Services Such as Policy Information 


9.1.4 


2.5.5 Refund Policy 


9.1.5 


2.6 Publication and Repository 


2. 


2.6.1 Publication of CA Information 


2.2,4.4.2,4.4.3,4.6.6,4.6.7, 
4.7.6,4.7.7,4.8.6,4.8.7 


2.6.2 Frequency of Publication 


2.3 


2.6.3 Access Controls 


2.4 


2.6.4 Repositories 


2.1 


2.7 Compliance Audit 


8. 


2.7.1 Frequency of Entity Compliance Audit 


8.1 


2.7.2 Identity/Qualifications of Auditor 


8.2 


2.7.3 Auditor's Relationship to Audited Party 


8.3 


2.7.4 Topics Covered by Audit 


8.4 


2.7.5 Actions Taken as a Result of Deficiency 


8.5 


2.7.6 Communications of Results 


8.6 


2.8 Confidentiality 


9.3, 9.4 


2.8.1 Types of Information to be Kept Confidential 


9.3.1,9.4.2 


2.8.2 Types of Information Not Considered Confidential 


9.3.2,9.4.3 


2.8.3 Disclosure of Certificate Revocation/Suspension Information 


9.3.1,9.3.2,9.3.3,9.4.2,9.4.3, 
9.4.4 


2.8.4 Release to Law Enforcement Officials 


9.3.3,9.4.6 


2.8.5 Release as Part of Civil Discovery 


9.3.3,9.4.6 


2.8.6 Disclosure Upon Owner's Request 


9.3.3,9.4.7 


2.8.7 Other Information Release Circumstances 


9.3.3,9.4.7 


2.9 Intellectual Property Rights 


9.5 


3. Identification and Authentication 


3. 


3.1 Initial Registration 


3.1,3.2 


3.1.1 Type of Names 


3.1.1 


3.1.2 Need for Names to be Meaningful 


3.1.2,3.1.3 


3.1 .3 Rules for Interpreting Various Name Forms 


3.1.4 


3.1 .4 Uniqueness of Names 


3.1.5 


3.1.5 Name Claim Dispute Resolution Procedure 


3.1.6 
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RFC 2527 Section 


RFC 3647 Section 


3.1.6 Recognition, Autinentication, and Role of Trademarl<s 


3.1.6 


3.1.7 Metinod to Prove Possession of Private Key 


3.2.1 


3.1.8 Autinentication of Organization Identity 


3.2.2 


3.1.9 Authentication of Individual Identity 


3.2.3 


3.2 Routine Re-key 


3.3.1,4.6,4.7 


3.3 Re-key After Revocation 


3.3.2 


3.4 Revocation Request 


3.4 


4. Operational Requirements 


4., 5. 


4.1 Certificate Application 


4.1,4.2,4.6,4.7 


4.2 Certificate Issuance 


4.2,4.3,4.4.3,4.6,4.7,4.8.4, 
4.8.6,4.8.7 


4.3 Certificate Acceptance 


4.3.2,4.4,4.6,4.7,4.8.4-4.8.7 


4.4 Certificate Suspension and Revocation 


4.8,4.9 


4.4.1 Circumstances for Revocation 


4.8.1,4.9.1 


4.4.2 Who Can Request Revocation 


4.8.2,4.9.2 


4.4.3 Procedure for Revocation Request 


4.8.3-4.8.7,4.9.3 


4.4.4 Revocation Request Grace Period 


4.9.4 


4.4.5 Circumstances for Suspension 


4.9.13 


4.4.6 Who Can Request Suspension 


4.9.14 


4.4.7 Procedure for Suspension Request 


4.9.15 


4.4.8 Limits on Suspension Period 


4.9.16 


4.4.9 CRL Issuance Frequency (If Applicable) 


4.9.7,4.9.8,4.10 


4.4.10 CRL Checking Requirements 


4.9.6,4.10 


4.4.11 On-Line Revocation/Status Checking Availability 


4.9.9,4.10 


4.4.12 On-Line Revocation Checking Requirements 


4.9.6,4.9.10,4.10 


4.4.13 Other Forms of Revocation Advertisements 


4.9.11,4.10 


4.4.14 Checking Requirements for Other Forms of Revocation 
Advertisements 


4.9.6,4.9.11,4.10 


4.4.15 Special Requirements re Key Compromise 


4.9.12 


4.5 Security Audit Procedures 


5.4 


4.5.1 Types of Events Recorded 


5.4.1 


4.5.2 Frequency of Processing Log 


5.4.2 


4.5.3 Retention Period for Audit Log 


5.4.3 


4.5.4 Protection of Audit Log 


5.4.4 


4.5.5 Audit Log Back-up Procedures 


5.4.5 


4.5.6 Audit Collection System (Internal vs. External) 


5.4.6 


4.5.7 Notification to Event-Causing Subject 


5.4.7 
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4.5.8 Vulnerability Assessments 


5.4.8 


4.6 Records Archival 


5.5 


4.6.1 Types of Records Archived 


5.5.1 


4.6.2 Retention Period for Archive 


5.5.2 


4.6.3 Protection of Archive 


5.5.3 


4.6.4 Archive Back-up Procedures 


5.5.4 


4.6.5 Requirements for Time-Stamping of Records 


5.5.5 


4.6.6 Archive Collection System (Internal or External) 


5.5.6 


4.6.7 Procedures to Obtain and Verify Archive Information 


5.5.7 


4.7 Key Changeover 


5.6 


4.8 Compromise and Disaster Recovery 


5.7, 5.7.1 


4.8.1 Computing Resources, Software, and/or Data Are Corrupted 


5.7.2 


4.8.2 Entity Public Key is Revoked 


4.9.7,4.9.9,4.9.11 


4.8.3 Entity Key is Compromised 


5.7.3 


4.8.4 Secure Facility After a Natural or Other Type of Disaster 


5.7.4 


4.9 CA Termination 


5.8 


5. Physical, Procedural, and Personnel Security Controls 


5. 


5.1 Physical Controls 


5.1 


5.1.1 Site Location and Construction 


5.1.1 


5.1.2 Physical Access 


5.1.2 


5.1 .3 Power and Air Conditioning 


5.1.3 


5.1 .4 Water Exposures 


5.1.4 


5.1.5 Fire Prevention and Protection 


5.1.5 


5.1.6 Media Storage 


5.1.6 


5.1.7 Waste Disposal 


5.1.7 


5.1.8 Off-Site Back-up 


5.1.8 


5.2 Procedural Controls 


5.2 


5.2.1 Trusted Roles 


5.2.1,5.2.4 


5.2.2 Number of Persons Required per Task 


5.2.2, 5.2.4 


5.2.3 Identification and Authentication for Each Role 


5.2.3 


5.3 Personnel Controls 


5.3 


5.3.1 Background, Qualifications, Experience, and Clearance 
Requirements 


5.3.1 


5.3.2 Background Check Procedures 


5.3.2 


5.3.3 Training Requirements 


5.3.3 


5.3.4 Retraining Frequency and Requirements 


5.3.4 


5.3.5 Job Rotation Frequency and Sequence 


5.3.5 
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5.3.6 Sanctions for Unauthorized Actions 


5.3.6 


5.3.7 Contracting Personnel Requirements 


5.3.7 


5.3.8 Documentation Supplied to Personnel 


5.3.8 


6. Technical Security Controls 


6. 


6.1 Key Pair Generation and Installation 


6.1 


6.1.1 Key Pair Generation 


6.1.1 


6.1 .2 Private Key Delivery to Entity 


6.1.2 


6.1 .3 Public Key Delivery to Certificate Issuer 


6.1.3 


6.1 .4 CA Public Key Delivery to Users 


6.1.4 


6.1.5 Key Sizes 


6.1.5 


6.1.6 Public Key Parameters Generation 


6.1.6 


6.1 .7 Parameter Quality Checking 


6.1.6 


6.1.8 Hardware/Software Key Generation 


6.1.1 


6.1 .9 Key Usage Purposes (as per X.509 v3 Key Usage Field) 


6.1.9 


6.2 Private Key Protection 


6.2 


6.2.1 Standards for Cryptographic Module 


6.2.1 


6.2.2 Private Key (n out of m) Multi-Person Control 


6.2.2 


6.2.3 Private Key Escrow 


6.2.3 


6.2.4 Private Key Back-up 


6.2.4 


6.2.5 Private Key Archival 


6.2.5 


6.2.6 Private Key Entry Into Cryptographic Module 


6.2.6,6.2.7 


6.2.7 Method of Activating Private Key 


6.2.8 


6.2.8 Method of Deactivating Private Key 


6.2.9 


6.2.9 Method of Destroying Private Key 


6.2.10 


6.3 Other Aspects of Key Pair Management 


6.3 


6.3.1 Public Key Archival 


6.3.1 


6.3.2 Usage Periods for the Public and Private Keys 


6.3.2 


6.4 Activation Data 


6.4 


6.4.1 Activation Data Generation and Installation 


6.4.1 


6.4.2 Activation Data Protection 


6.4.2 


6.4.3 Other Aspects of Activation Data 


6.4.3 


6.5 Computer Security Controls 


6.5 


6.5.1 Specific Computer Security Technical Requirements 


6.5.1 


6.5.2 Computer Security Rating 


6.5.2 


6.6 Life Cycle Technical Controls 


6.6 


6.6.1 System Development Controls 


6.6.1 
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6.6.2 Security Management Controls 


6.6.2 


6.6.3 Life Cycle Security Controls 


6.6.3 


6.7 Network Security Controls 


6.7 


6.8 Cryptographic Module Engineering Controls 


6.2.1,6.2,6.2.1,6.2.11 


7. Certificate and CRL Profiles 


7. 


7.1 Certificate Profile 


7.1 


7.1.1 Version Number(s) 


7.1.1 


7.1.2 Certificate Extensions 


7.1.2 


7.1.3 Algorithm Object Identifiers 


7.1.3 


7.1.4 Name Forms 


7.1.4 


7.1.5 Name Constraints 


7.1.5 


7.1 .6 Certificate Policy Object Identifier 


7.1.6 


7.1.7 Usage of Policy Constraints Extension 


7.1.7 


7.1.8 Processing Semantics for the Critical Certificate Policies Extension 


7.1.8 


7.2 CRL Profile 


7.2 


7.2.1 Version Number(s) 


7.2.1 


7.2.2 CRL and CRL Entry Extensions 


7.2.1 


8. Specification Administration 


N/A 


8.1 Specification Change Procedures 


9.12 


8.2 Publication and Notification Policies 


2.2, 2.3 


8.3 CPS Approval Procedures 


1.5.4 
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